devops java
![连续交付书籍封面实用指南](https://i-blog.csdnimg.cn/blog_migrate/ccc07d2fdc9f299b4b7ec06150c25ecc.png)
埃伯哈德·沃尔夫专访
Cameron McKenzie: Eberhard Wolff是服务器端在Twitter上关注的专家之一。 一位具有20年经验的软件工程师,您可能已经读过他的一本有关Spring或持续交付或微服务的书,或者您可能已经看到他在北美的一次会议上就其中一个主题发表演讲,或者欧洲。 我们注意到他有一本新书《 持续交付实用指南 》,所以我们安排了一次采访,第一个问题是,“持续集成和持续交付的当前状态是什么?”
埃伯哈德·沃尔夫(Eberhard Wolff):我想说,如今,持续集成已经成为一种商品,人们实际上已经忘记了它的真正含义。 他们开始使用连续集成只是为了进行常规编译,而实际上,他们正在进行功能分支,从而推迟了集成。 通常,人们实际上是在进行功能分支,这意味着团队可能在很长一段时间内都在做某事,而没有进行集成。 他们有点想念关于持续集成的原始观点。 因此,我认为这就是我们所处的状态,人们实际上已经忘记了持续交付背后的原始想法,现在正在重新发现它们。
卡梅隆·麦肯齐(Cameron McKenzie):因此,当您使用这种功能分支方法遇到客户时,您会告诉他们什么以及如何去纠正他们?
Eberhard Wolff:我首先告诉他们的是,如果您没有问题,请不要解决。 功能分支实际上是一种很好的方法。 如果他们确实有问题,无法重新集成到主分支中,那么我将设置一些其他措施,例如进行常规集成,或者甚至完全更改它,以便只拥有master分支,并在干线上进行所有工作。
连续交付会稍微改变整个事情,因为通常这意味着master分支很特别,因为它是进入生产的分支。 即使您具有功能分支并分支了它们,它们也与主分支有所不同,因为它们通常不会投入生产。 这就是说,我认为通过连续交付,将要素分支组合在一起并不是最好的主意。
卡梅隆·麦肯齐(Cameron McKenzie):现在,您是否向要采用持续交付方式开发DevOps的组织推荐任何软件工具,或者您是那些认为工具是最后一件事的倡导者之一?你说什么时候走这条路?
Eberhard Wolff: Concourse CI是一个有趣的工具,因为它可以在Docker上执行所有操作。 实际上,我的一位同事对此很拥护,所以我发现这很有趣。 一般而言,我会特别争论,如果您谈论连续交付,并且您看这本书,那么实际上就是测试。
因此,在本书中,我将讨论单元测试,验收测试,性能测试以及所有这些事情。 通常,如果我去找客户,需要咨询他们有关持续交付以及微服务的信息,那么与他们交谈的第一件事就是:“实际上是什么使您无法进行更频繁的发布?” 通常会有一些手动签收或一些手动验收测试,我认为这是经常被遗忘的东西。 因此,您知道,仅拥有Jenkins并进行部署自动化,我认为这并不是关键的挑战。 关键的挑战是要在没有人工签核的情况下投入生产。
卡梅隆·麦肯齐(Cameron McKenzie):现在,我们都熟悉单元测试和测试我们的业务逻辑,甚至在一定程度上还集成测试,但是测试UI呢? 我的意思是,我们如何才能对用户界面进行更改,以使人们与工具交互并实际对其进行测试和验证? 在自动化UI测试方面是否存在一些严峻的挑战?
Eberhard Wolff:我倾向于同意,如果您谈论涉及,您知道,外观和感觉以及此类事情的UI测试,那将很难实现自动化,甚至可能是不可能的。 话虽如此,我通常在客户中看到的是他们依赖UI。 他们正在做UI测试,但我认为他们真正在做的是验收测试。 因此,您知道,这与“ UI是否正常工作”无关,也与“ UI看起来不错”无关。 如果他们进行自动化的UI测试,通常是系统完成了应做的工作 ,我认为这就是验收测试。
通常通向测试人员的道路,对吗? 他们启动应用程序,看一下UI,在UI中做一些事情,验证结果是否正确,然后自动执行。 因此,您有一个UI测试,实际上,这实际上是一个验收测试。 我认为这很糟糕,因为那样会导致脆弱的测试,因为如果对UI进行细微调整,即使业务逻辑可能仍然相同,也会破坏测试。 而且,这些测试往往很慢,有时甚至不可靠。
因此,如果您问有关UI测试的主要挑战,我会认为主要挑战是它们成为验收测试,并且您应该在这方面研究进行测试的不同方式,并且您应该适当地接受使用其他工具进行测试。 这就是为什么我真的想加入有关行为驱动设计的那一章的原因,因为我认为了解如何进行适当的自动验收测试以及如何避免客户手动签收是关键。
卡梅隆·麦肯齐(Cameron McKenzie):现在,您显然在手动签核上遇到了问题,但是探索性测试又如何呢? 我相信您在书中谈到了它。 探索性测试的作用以及探索性测试的手动方面是什么?
Eberhard Wolff:我认为可以进行手动测试。 我的意思是,这基本上就是对探索性测试的意义,您可以手动查看导致问题或类似问题的应用程序的特定部分。 因此,我认为这是一个工具,您可以在其中专门关注应用程序的特定领域,从性能的角度,从业务逻辑的角度等,都可以解决问题。
您知道,要解决特定领域中的问题,这是正在进行的事情,但这不应该成为持续交付流程中的障碍,而这显然是需要签字的情况。
Cameron McKenzie:现在,无可否认的是容器化趋势,我看到越来越多的客户被迫使用Docker并将Docker和容器集成到他们的体系结构中。 容器化和诸如Docker之类的工具如何改变完成持续集成和持续交付的方式?
埃伯哈德·沃尔夫(Eberhard Wolff):是的,我认为您的意思很重要。 Docker允许采用不同的方式进行集成和持续集成等。 我同意可能会有新一代的工具。 我相信Concourse是已经提到的工具之一。 因此,我认为这是一个有趣的观点,您可以真正地重新考虑持续集成,使连续集成服务器了解Docker容器,使连续集成服务器本身在Docker容器中运行以及明显地创建Docker容器。 我相信,我应该怎么说,詹金斯仍然不是最好的工具,对吗? 因此,我认为,由于这个原因,您在转向Docker时提到的额外压力令我感到欢迎,因为我期待新一代CI工具。
Cameron McKenzie:那么您希望在下一代持续集成和持续交付工具中看到什么?
Eberhard Wolff:对不同项目的不同版本进行更严格的隔离。 如果您看一下Jenkins,我会说它的建立是出于建立持续集成平台,工具本身和Web UI中的持续集成管道的想法。 当然,这已经改变了,因为现在有了工作描述语言。 但是我认为,理想情况下,现代的持续集成工具无论如何都应该基于代码。 因此,您知道,从一开始就有一个持续集成管道的工作描述,应该牢记这一点。 所以我认为这些都是重点。
当然,我对Jenkins的喜好是庞大的生态系统和您拥有的所有插件,这又是一个问题,因为这意味着没有Jenkins服务器看起来像另一个,而且很难获得所有这些插件可以一起工作。 因此,这可能是另一个缺点,但是,这是折衷方案,因为如果不是针对这些插件,那么Jenkins的价值将大大降低。
卡梅隆·麦肯齐(Cameron McKenzie):因此,我假设您相信采用DevOps文化对于进行持续集成和持续交付工作至关重要。
埃伯哈德·沃尔夫(Eberhard Wolff):好的,是的。 因此,我认为DevOps完全是有关开发和运营一起工作的,也就是说,这与组织变革无关,因此我认为让开发人员和运营人员向同一位经理报告并没有那么重要。 我认为重要的是,这两者都应承担应用程序的责任,并且没有指责,只有真正的协作。 所以我认为这是关键。 当然,如果您确实要更改组织,那么这对于此类协作可能是有益的。
我认为,持续交付是通过DevOps可以更轻松地实现的一种方法或一件事。 这就是说,如果我从某个角度来看连续交付管道,那就是将物料部署到生产中,这通常是操作的事情。 另一方面,如果管道的开始,只是进行编译和构建软件,然后进行单元测试,那就更像是开发人员了。 因此,如果您拥有整个管道,那么只有拥有DevOps组织才能构建它。 因此,说说持续交付是拥有DevOps组织可以实现的一件事。 在我看来,这就是如何组合在一起的方式。
卡梅隆·麦肯齐(Cameron McKenzie):现在,我们今天聚在一起的原因之一是,我们可以讨论您的最新著作“连续交付实用指南”。 您想要通过编写本书来实现什么目标?一旦读者阅读完本书,将会收获什么?
埃伯哈德·沃尔夫(Eberhard Wolff):我想用我的书实现什么,实际上,它与实用的介绍也与最初的“连续交付”书有所不同。 所以我实际上在谈论特定的工具。 我提供有关如何使用它们的建议。 我有一些使用工具的示例。 人们可以从中学习并建立自己的实验。 我认为这基本上就是它的工作方式。
卡梅伦·麦肯齐(Cameron McKenzie):现在,如果这种对话不能说服您埃伯哈德·沃尔夫(Eberhard Wolff)知道他在说什么,我不知道会怎样。 我强烈建议您像服务器端一样,在Twitter上关注他。 那是@ewolff。 那是两个F。 更重要的是,去拿起他的书“ 连续交付实用指南 ”。 我知道你会喜欢的。
您可以在Twitter上关注Cameron McKenzie: @cameronmcnz 您也可以关注Eberhard Wolff: @ewolff
如何成为詹金斯专家
努力学习詹金斯? 查看这些很棒的循序渐进的Jenkins CI教程。 他们会让您很快成为Jenkins CI专家。
步骤1 — 下载Jenkins并安装 CI工具
第2步-创建您的第一个Jenkins构建作业教程
第3步-将Jenkins环境变量注入脚本
步骤4 —修正烦人的Jenkins插件错误
第5步-将詹金斯与Maven辩论甩在身后
第6步—学习使用布尔值和字符串詹金斯参数
步骤7 —做一个Jenkins Git插件GitHub拉
步骤8 —将基本的Git命令知识添加到您的DevOps技能集中
devops java