江苏龙网

  1. 首页 > 资讯 > 科技 > >

[]深入了解CI/CD：工具、方法、环境、基础架构的全面指南( 二 )


本文插图

不过 ， 就算有分支机制也并非一帆风顺 。 即使开发人员每天提交代码 ， 冲突仍然会发生 。 因为其他团队成员会继续做出更改 ， 而没有考虑各方的诉求 。 实际上 ， 集成问题经常需要返工 ， 包括手动合并冲突的更改 。 但是比起开发团队整周或一个月都在埋头工作而不处理冲突 ， 找出并解决一天工作中的冲突要简单很多 。 因此 ， 尽管无法避免集成问题 ， 但CI可以大大减少集成问题 。
3、部署流水线和自动化测试
QA的部分工作是找出错误并确保代码是可部署的 。 传统流程中 ， 在部署完成后会由一个单独的团队来负责QA 。 因为开发人员通常每年仅执行几次测试 ， 因此在引入更改几个月后他们才了解到错误 。 到那时 ， 因果之间的联系可能已经很难查证 ， 导致诊断越来越困难 。 但是自动化测试解决了这个问题 。
使用部署流水线之后 ， 每次将代码添加到版本控制中都会触发一系列测试 。 流水线会自动构建和测试代码以确保它可以按预期工作 ， 并且一旦集成到代码库中就可以继续工作 。 虽然在测试环境中代码可以完美执行 ， 但它仍有可能在生产环境中不幸失败 ， 因为生产中的环境和所有依赖项都会影响代码性能 。 依赖项并不属于app中的一部分 ， 但仍需要运行它 。 例如数据库、数据/对象存储以及服务和应用程序可能需要调用的API 。 因此 ， 开发和测试环境必须模仿生产环境 。 另外 ， 必须对所有依赖项进行代码测试 。

[]深入了解CI/CD：工具、方法、环境、基础架构的全面指南
本文插图

简而言之 ， 部署代码时有3个测试阶段 ， 每个阶段都会额外增加复杂性：
（1）验证代码本身是否按照预期工作；
（2）在代码库中继续进行验证；
（3）验证性能在具有所有依赖项的类生产环境中保持不变 。
如果代码每天都被提交到版本控制中 ， 则可以对其进行自动化测试 ， 并且在引入代码之日会标记出任何构建、测试或集成错误 ， 从而可以立即进行修复 。 这确保代码总是处于可部署和可运送的状态 ， 称为绿色构建 。
自动测试允许开发人员提高测试和集成的频率——从周期性执行到持续测试集成 ， 并在约束最少的情况下发现问题 。 最糟糕的情况也不过是一天的工作都浪费了 。
关于版本控制的争议
关于是否改在版本控制中存储敏感信息（如 access token、密钥和密码）进行了一些讨论 。 一方面 ， 有人认为应该将一切（包括secret）都存储在这里 ， 从而将这一方法推向极限 。 但是有人认为这是不良做法 ， 并认为敏感信息应该单独存储 。
版本控制允许开发人员比较、合并和还原以前的修订 。 通过允许他们在出现问题时将生产中的系统快速还原到以前的版本 ， 从而将风险降到最低 。 为此 ， 无论版本多小 ， 所有更新和更改都必须在版本控制中进行跟踪 。 如果不是这样 ， 生产中的代码将开发和测试环境中的代码不匹配 ， 从而导致不一致 。
简而言之 ， 版本控制是事实的单一来源 ， 包含了系统的预期状态以及所有以前的状态 。 通过将所有生产环境中的组件放置到版本控制中 ， 开发人员可以重复可靠地重现工作软件系统中的所有组件 。 这是启用所谓的不可变基础架构的关键 ， 我们将在稍后讨论 。
持续交付：扩展CI以实现流畅的代码部署
即使使用了持续集成 ， 将代码部署到生产中的过程依旧是手动、乏味且容易出错的 。 如果真是这样 ， 那么显然不会频繁地将代码部署到生产中 。 IT部门会尽可能避免执行艰巨而危险的任务 ， 这会导致要部署的代码与生产中运行的代码之间差异越来越大 ， 进一步加具危险 ， 然后形成一种恶性循环 。 那么解决这一恶性循环的答案是启用CI/CD中的CD部分 。
CD扩展了CI ， 确保在将代码推广到整个用户群之前让代码在生产环境中能够平滑运行 。 最常见的CD方法是金丝雀和蓝绿部署 。


推荐阅读


上一篇：『』阿里推出“阿里云会议”

下一篇：#得意的西红柿#苹果推送 IOS12.4.6到底值不值得升级，我来告诉你