devops [DevTestOps]-持续发布最佳实践

rocl · 2018年01月03日 · 2671 次阅读

持续发布是一种方法或软件策略, 代码更改会自动编译、测试和准备发布到生产中。连续的交付使代码部署成为可能在任何时候通过一次单击。在任何环境中, 在每次部署之前, 连续交付都要处理测试过程。它首先运行可能的测试套件, 可以是回归测试、集成测试、负载测试等来测试代码, 如果仅通过测试, 则只在相应的环境中部署代码。我们甚至可以自动化整个过程以确保 不停机的部署, 因此不会涉及停机时间, 因此不会对业务造成影响。

基本上, 持续交付的目标是通过自动化的软件生产线使不同环境的变化持续不断。连续交付允许推出比以前的迭代更好的新功能和功能, 因此在整个组织中逐步整合和细化持续交付原则。这种方法为敏捷软件团队提供快速反馈, 以响应市场需求并迅速消除问题。

为什么公司需要持续发布:

1.产品质量得到提高→ 由于部署是自动化的, 它更频繁地发生, 这让开发团队经常和快速地获得必要的用户建议和反馈。这些反馈给出了在重要特性上工作的想法, 而不浪费时间在其他无关紧要的特性上。这有助于使代码和产品质量得到改进, 并做出正确的产品。

2.对变化反应迅速→ 当我们谈论技术市场的变化时, 公司总是面临挑战。很难跟上技术的变化。如果我们花费太长的时间在任何事情上, 当我们交付产品的时候, 也许有一个机会, 技术要求改变或新的机会已经出现。持续的交付使得在不投入大量时间和金钱的情况下, 对这些变化作出快速反应成为可能。这也使公司对机会作出反应, 寻找新的想法和潜在的新的收入来源。

3.稳定性和可靠性→ 由于部署频繁, 并且以非常小的增量进行更改可减少导致问题的风险。此外, 通过保持较小的变化更容易找到和解决问题, 如果它发生, 因此导致最小化的金钱和时间。通过这样做, 持续发布团队可以维护代码和产品的稳定性和可靠性比以前更好。

4.节省时间→ 如果组织不应用持续交付方法, 那么提供环境、查找 bug 和解决它们是一项非常繁琐的任务。使用 CD 方法可以实现上述步骤的自动化, 因此需要自动化此过程。这样可以节省大量时间, 并使组织能够提供更多的业务价值。

5.战略影响→ 以上各点都给出了由于频繁的用户反馈、早期发布的好处、业务创新、可靠性和稳定性而使产品更好、更高效的组织文化的战略影响。组织想要什么。这就是为什么我们必须持续交付。

实现持续发布的最佳做法:

实现 CD 最大的挑战是找到在最短的时间内在不同环境中自动化构建和测试的最佳方法。持续发布 Pipeline 和编译 Pipeline 使这一切发生。发布 Pipeline 是通过将交付过程分解为各种构建来处理此问题的一种方法。通过提供反馈, 每个构建都增加了信心。Pipeline 分阶段中断交付过程。每个阶段都旨在从不同角度测试代码和功能的质量, 以验证新功能并防止错误。有各种工具可以帮助实现整个过程的自动化。

1.生成编译 Pipeline→ 编译 Pipeline 由在特定环境中执行的各种作业 (Jobs) 组成。编译 Pipeline 中的下一个作业 (Jobs) 将在以前执行的作业成功运行之后执行, 否则 Pipeline 将被中止。工作 (Jobs) 和构建自动化的整个过程由一个名为 Jenkins 的 CI\CD 工具管理。Jenkins 是一个应用程序, 允许连续集成和连续交付的项目, 无论你正在工作的平台。它是一个自由的来源, 可以处理任何类型的构建或持续集成。Jenkins 也可以与其他部署技术集成。

  • A. 从 BitBucket 中提取代码→ BitBucket 是一个版本控制软件工具, 可以帮助软件团队随着时间的推移管理源代码。BitBucket 跟踪代码中的更改, 以便我们可以在任何时候恢复所做的更改。它允许团队成员同时推动代码。如果所做的更改是相互冲突的, 那么它可以有条不紊地解决, 而不会阻碍团队其他成员的工作。现在, 我们做一个工作, 只要在源代码发生变化时就会拉动代码。

  • B. 运行单元测试 → 第二个作业, 它在应用程序的较新版本上运行单元测试套件, 以确保它满足所有所需的要求。重要的是, 所有重要的方面, 如功能的验证时, 更新的版本被上传。

  • C. Build the code 构建代码 → 当代码被完全测试后, 代码就是构建, 它将代码编译、链接和打包成可用的或可执行的形式。为此, 我们使用生成工具, 这些程序是从源代码中自动创建可执行应用程序的。使用自动化工具可以使生成过程更加一致。为了获得最佳效果, 我们可以使用 MAVEN 或 GRADLE 作为构建工具。使用 MAVEN 的最佳部分是其生命周期。由于该项目依赖于某些标准, 因此 maven 可以更轻松地通过生命周期。生成工具将源代码打包成易于部署的 WAR 或 JAR。

  • D.代码分析 → 对于每个项目来说, 代码的质量是非常重要的, 找出潜在的错误或不良的编码风格和做法。有各种各样的代码分析工具, 它们使用算法和技术的集合来分析源代码。SONARQUBE 是开源工具, 用于连续检查代码。Sonarqube 提供了配置规则、警报、阈值、排除、在线设置等功能。代码分析能够快速发现技术债务中的项目组件或模块, 以完成或制定行动计划。

  • E. 部署自动化 → 部署工具使应用程序定期自动化部署, 从而更方便地更改应用程序的配置。像 Ansible 这样的工具将工作流业务流程与资源调配、配置管理和应用程序部署结合起来。在部署之后, 我们可以运行回归测试并使用硒来自动化这些测试。

  • F. Slack 通知频道 → 必须有一个集中的渠道, 每个人都可以通过发送和获取通知来直接访问和监视任何类型的活动。这有助于与所执行的活动保持联系。

2. 生成发布 Pipeline → 当在环境中自动执行作业时, 它称为构建 Pipeline。当作业的执行在不同的环境中自动完成时, 它被称为发布 Pipeline。以下是持续交付的各阶段:

  • 1.使用构建管道在开发环境中测试和编译代码。
  • 2.最终结果文件 (artifact) 将被推送到工件或类似 nexus, Jfrog。
  • 3.应用程序将被部署到 stage 环境和回归测试,使用的工具, 如 Selenium 进行测试。
  • 4.应用程序将部署在预生产环境中, 并使用像 Jmeter 这样的工具完成负载测试。
  • 5.在任何阶段, 都应通过使用 Slack 通道上的通知向团队成员、客户提供反馈。

现在, 代码已准备好部署到生产环境中。

执行上述步骤后, 可以在生产环境中部署该生成。
通过遵循上述方法, 您可以在基础结构中使用持续发布的最佳做法, 以使您的生活更轻松。

我想提一下我特别鸣谢勒凯什·索德马哈詹分享他的广博的知识和帮助我写这个博客。
在我的下一篇博客中, 我将会写下持续的部署最佳实践。

参考文档
http://www.tothenew.com/blog/continuous-delivery-best-practices/

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 0 条回复 时间 点赞
rocl [DevTestOps]---开篇综述 中提及了此贴 01月03日 16:17
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册