江苏龙网

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

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


进行蓝绿部署期间 ， IT会与当前版本一起部署一个新的组件或应用程序版本 。 新版本（绿）被部署到生产中并对其进行测试 ， 与此同时当前版本（蓝）依旧可以使用 。 如果新版本的代码运行良好 ， 那么所有用户将会切换到新版本中 。
金丝雀部署也有两个版本：当前版本和更新版本 。 IT开始将一小部分用户请求路由到新版本 。 代码和用户的行为会被持续监控 。 如果错误率或用户投诉并没有增加 ， 则路由到新版本的请求份额将逐渐增加（例如 ， 1%、10%、50%最后到100%） 。 一旦所有请求都发送到新版本中 ， 那么旧版本就会自动退休或删除 。
通过按需环境创建自助服务
现在 ， 我们已经研究了CI、CD及其各自的工具和方法 ， 下面我们来讨论环境和基础架构 。 CI / CD需要一种创新的方法 。
如我们所见 ， 自动化测试使开发人员可以自己执行QA 。 为了确保一切都能在生产中正常运行 ， 他们必须在整个开发和测试过程中使用类似于生产的环境 。
传统上 ， 开发人员必须向Ops团队请求（手动）设置的测试环境 。 此过程可能需要数周 ， 有时甚至数月 。 此外 ， 手动部署的测试环境通常会出现配置错误 ， 或者与生产环境有很大差异 ， 因此即使代码通过了所有预部署测试 ， 仍然会导致生产问题 。
CI / CD的关键部分是为开发人员提供按需类似于生产的环境 ， 使其可以在自己的工作站上运行 。 为什么这很重要？开发人员只有在相同的条件下进行部署和测试时 ， 才能知道代码在生产中的行为 。 如果他们在不同的环境中测试代码 ， 则当最终将代码部署到生产环境中时 ， 他们可能会发现代码不兼容 ， 那么此时对客户造成了重大影响 ， 再解决问题已经为时已晚 。
不可变基础设施：牛与宠物
在讨论版本控制系统时 ， 我们谈到了将环境与所有其他应用程序组件进行编码的需求 ， 接下来让我们进一步讨论这些环境 。
如果在版本控制中定义了环境规范并进行了编码 ， 那么在容量增加（水平扩展）时复制环境就像按一个按钮一样简单（尽管之后它很有可能通过Kubernetes自动化了） 。
扩展意味着在高峰时段增加计算能力 。 例如 ， Netflix的使用率在每个星期五晚上达到峰值 ， 然后在午夜之后的某个时间再次恢复正常 。 为了确保享受无缓冲的视频 ， Netflix复制了其流控制组件（已在版本控制中进行了编码） ， 以满足需求 。 然后 ， 流量恢复后所有所谓的副本都被破坏 ， 使流容量恢复正常 。
为了实现这一点 ， 至关重要的是 ， 每当实施基础架构或应用程序更新时 ， 这些基础架构或应用程序都会自动复制到其他地方并置于版本控制中 。 这将确保无论何时创建新环境 ， 它都将与整个流水线（从dev到QA到生产）的环境匹配 。 例如 ， 如果Netflix要更新其流服务而忘了捕获版本控制的更改 ， 它将在高峰时段复制有故障或过时的组件 ， 从而导致问题甚至服务中断 。
由于掌握了版本控制中的环境编码 ， 因此手动更改环境不是最佳实践 ， 因为任何手动操作都容易出错 。 而应该将更改放入版本控制中 ， 并从头开始重新创建环境（和代码） 。 这称为不可变基础架构 。 这些与CI / CD部分中讨论的应用于基础架构的原则相同 。
你也许听过牛与宠物的比喻 。 这个比喻放在这里十分合适 。 以前 ， 基础设施被视为宠物 。 如果有问题 ， 你会尽力解决它 ， 以便它可以生存 。 今天 ， 基础设施被视为牛 。 如果它无法正常工作或需要更新 ， 请杀死它并启动新环境 。 这非常强大 ， 并且大大降低了问题潜入系统的风险 。
发布与部署解耦
传统上 ， 软件发布是由市场启动日期驱动的 。 因此 ， 要发布的新功能会在宣布日期的前一天部署到生产中 。 但是 ， 我们知道将特性或更新发布到生产中总是有风险的 ， 尤其是如果你一次发布整个特性时 。 因此 ， 将部署与发布捆绑在一起将使IT部门总是需要为失败胆战心惊 。 试想一下 ， 如果在广泛推广的前一天发生了重大问题 ， IT团队就会感到恐慌 ， 并且会在客户和媒体中引起巨大不良反响 。


推荐阅读


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

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