持续交付 devops_通过DevOps和持续交付实现业务敏捷性

持续交付 devops

持续交付和DevOps的原则已经存在了几年。 遵循精益创业运动的开发人员和系统管理员对两者都非常熟悉。 但是，与新时代的Web 2.0型组织（如Flickr）或硅谷初创公司（如Instagram）相比，在传统的大型IT环境中实现这两者或两者往往是一项重大挑战。 这是一个案例研究，说明我所服务的咨询公司如何在使用一个蓝筹股客户的同时提供了最大的软件升级。

背景

客户是澳大利亚最大的零售商之一。 我所服务的公司是一家值得信赖的顾问，与他们合作已有十年之久。 在此期间（非常感谢），我们赢得了足够的信誉，可以影响严重依赖于IT基础架构的业务决策。

当我们的客户希望利用他们的忠诚度奖励计划来正面应对竞争时，即将进行大规模的IT基础架构升级。 现有用户数百万，我们的客户希望通过新的推广活动使这一数字翻一番，因此，该软件的期望不容小spectacular。 除了增加现有软件外，还需要安装一套新软件，该软件能够每小时处理数十万个新用户注册。 一旦系统上线（尤其是在市场营销活动期间），则无法选择停机维护（是吗？）。

为什么选择DevOps？

我们与该客户的长期关系以及IT运营的组织方式意味着采用DevOps的过程具有革命性，而不是革命性。 精通业务的人对我们的开发人员有着良好的尊重和信任，并且感觉是相互的。 我们的顾问为该软件提供了开发和24/7全天候支持。 该软件包括Web门户，后台系统，合作伙伴集成系统和客户支持系统。

采用DevOps原则意味着；

• 从开发到生产，我们的开发人员可以更好地控制软件在其中运行的环境。
• 与本地计算机相反，开发人员对软件最终运行的生产环境有更好的了解。
• 开发人员能够向基础架构运营团队清楚地说明该软件在每种环境中的功能。
• 简单明了的流程来管理变更的交付。
• 开发人员与运营部门之间更好的协作。 无需加票。

为什么要连续交付？

最重要的原因是降低了客户新广告系列的风险。 随着大规模的营销活动全面开展，针对数百万新用户注册，软件系统需要维持100％的正常运行时间。 使软件脱机进行维护，意味着失去业务机会和金钱。
简而言之;

• 大爆炸方法对于最初的发行本就很好。 但是，当发现问题时，我们希望在不停机的情况下提供修复程序。
• 当市场营销活动运行时，需要根据分析和指标对软件进行改进和改进。 大量交付（需要数月）不能带来良好的商业价值。
• 从开发人员的角度来看，经常进行小的更改有助于轻松找出问题所在，并回滚或重新部署修补程序。
• 我们在客户所在地遵循多年的敏捷实践，确保了适当的文化以无痛地采用连续交付。
• 我们已经在使用Hudson / Jenkins进行持续集成。
• 我们只需要构建部署管道的“最后一英里”，即可将现有技术流程升级为持续交付的流程。

过程：保持简单透明

我们遵循的开发过程很简单，文化也是如此，每个开发人员都知道，在任何给定的时刻，他们的一个或多个提交都可以发布到生产中。 为了使负担最小化，我们使用Subversion标记和分支，以便在将候选发布版本升级到测试环境之前对其进行标记，以供发布候选版本使用（稍后会详细介绍）。 尽早标记的优点是我们可以更好地控制交付到生产中的变更。 例如，错误修复与功能发布。

图片来源–维基百科

生产环境由二十个节点组成的集群。 每个节点都包含一个以Apache为首的Tomcat实例。 负载平衡器提供了在需要时从集群释放节点的功能，尽管不如Amazon弹性负载平衡器提供的API级别通信先进（这是客户端的一项投资，因此我们选择与其合作而不是抱怨） 。
Jenkins CI被用作我们持续交付过程的基础。 部署管道包括几个阶段。 与上图一样，我们将过程保持简单，以最大程度地减少混乱。

1.Build –在这个阶段，Jenkins在构建服务器上签出了Subversion的最新版本，运行了单元测试，一旦成功，便捆绑了工件。 构建环境还配备了用于测试部署软件以进行验证的基础结构。 Jenkins将每个构建都部署到此测试基础结构。

使用Subversion标记创建候选发布版本。

晋升任务

2.Test（UAT） –开发人员验证了构建后，便使用Jenkins任务将其升级到测试环境。

• 促销表明开发人员对构建有信心，并且可以进行质量保证。
• 自动促销过程使用打包到工件中的修订信息在Subversion中创建标签。
• 使用Selenium编写的自动集成测试针对Test部署运行。
• 质量检查小组使用此环境进行测试。

3.生产验证 –测试团队对工件进行了测试，并且自动集成测试未报告任何故障之后，便从生产集群中选择了一个节点，并使用Jenkins作业为烟气测试做好了准备。 该自动化过程将；

• 从集群中删除选定的节点。
• 将经过测试的工件部署到该节点。

从生产集群中删除节点。

提名一个或多个节点进行生产验证。

4.生产（转换） –烟雾测试完成后，工件将通过单独的Jenkins任务部署到集群。

• 部署遵循轮询调度，其中每个节点都从负载均衡器中移出，以部署和刷新软件。
• 部署时间是高度可预测的，几乎是恒定的。
• 一旦节点返回集群，验证就开始。

5.Rollback（灾难恢复） –在部署不佳的情况下，尽管进行了所有测试和验证，仍回滚到最后一个稳定的部署。 就像上面的过渡部署一样，时间对于
全面回滚。

准备回滚–回滚过程通过测试服务器。

实施：我们的工具

• Jenkins – Jenkins是整个过程的用户界面。 每当我们需要开发人员与特定工作进行交互时，我们就使用参数化的构建。
• Jenkins Batch Task插件 –我们将所有重复性任务自动化，以最大程度地减少人为错误。 任务插件得到了广泛的使用，因此我们可以灵活地编写脚本来完成我们想要的事情。
• Bash –大多数艰苦的工作都是由一组Bash脚本完成的。 我们通过适当的权限从构建服务器配置了无密钥登录，因此一旦通过Jenkins告诉他们该怎么做，这些脚本就可以像人类一样执行。
• Ant –该软件的构建脚本是用Ant编写的。 蚂蚁还可以与Jenkins很好地结合，并且可以在需要时从Shell脚本轻松调用。
• JUnit和Selenium –自动化很棒，但是如果没有良好的反馈循环，则可能导致灾难。 JUnit测试为我们提供了每个构建的反馈，而Selenium对于升级到测试环境的构建也提供反馈。 错误意味着将立即终止该构建的部署管道。 加上质量检查人员进行的测试，可将缺陷降至最低。
• Puppet –操作团队使用Puppet（ http://puppetlabs.com ）管理跨环境的配置。 运营团队为开发人员构建服务器后，他们将拥有完全访问权限并对其进行配置以运行应用程序。 最重要的部分是记录我们在那里所做的一切。 一旦开发人员对配置有效感到满意，他们将向操作团队提供一个演练，他们将依次更新其木偶食谱。 这些更改立即由Puppet部署到群集中。
• 监控 –所有生产节点的日志都被收集到一个位置以便于分析。 应用程序本身内置了运行状况检查页面，因此我们可以检查每个节点上运行的应用程序的状态。

结论

DevOps和持续交付都不是灵丹妙药。 但是，培育一种文化，使开发人员和运营人员相互信任并一起工作，对于企业而言是非常有益的。 培养这种文化可以使企业获得敏捷开发过程的全部好处。 由于我们（开发人员）和客户的运营团队之间的相互信任，我们能够实施一个部署管道，该管道能够在必要时数小时内而不是数月内交付功能和修复。 在关键的营销活动中，这种敏捷性使我们的客户能够通过其营销分析和KPI收到的反馈使软件基础架构保持与时俱进。

进一步阅读

您可能会发现一些有趣的文章。

• 低风险软件发布的四个原则
• 在DVCS上，持续集成和功能分支
• 开发运营与持续交付之间的关系

参考：我们的JCG合作伙伴 Tyrell Perera在Conundrum博客上通过DevOps和持续交付实现业务敏捷性 。

翻译自: https://www.javacodegeeks.com/2012/10/business-agility-through-devops-and.html

持续交付 devops