微服务的持续交付 - 基于主干的开发和功能切换
这是微服务](https://www.gocd.org/tags/cd-for-microservices.html)系列[CD 中的第三篇文章。在之前的帖子中,我们谈到了在微服务架构上构建 CD 管道的测试策略。在这篇文章中,我们将深入了解 CI 实践。 持续集成 持续集成是成功的持续交付策略的关键实践。简而言之,这是一种要求开发人员每天多次将他们的代码集成到共享存储库中的做法。每次签入都通过自
这是微服务](https://www.gocd.org/tags/cd-for-microservices.html)系列[CD 中的第三篇文章。在之前的帖子中,我们谈到了在微服务架构上构建 CD 管道的测试策略。在这篇文章中,我们将深入了解 CI 实践。
持续集成
持续集成是成功的持续交付策略的关键实践。简而言之,这是一种要求开发人员每天多次将他们的代码集成到共享存储库中的做法。每次签入都通过自动构建进行验证,使团队能够及早发现问题。
我们将专注于两个关键实践,基于主干的开发和功能切换。这两者在实施简单而强大的 CI 流程方面大有帮助。
基于主干的开发
在基于主干的开发 (TBD) 中,开发人员在称为“主干”的单个分支中协作处理代码。主要好处是避免开发分支中的漂移和由此产生的合并地狱。
[](https://res.cloudinary.com/practicaldev/image/fetch/s--192u9omq--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cl .ly/b86f90a7fe30/download/Image%25202019-04-04%2520at%25206.42.23%2520PM.png)
这与维护长期存在的特性和发布分支的做法背道而驰。在分支模型中,尽管您可能在单个分支上运行构建,但可以说您没有进行持续集成。在基于主干的开发中,您永远不会发现主干处于无法部署 CD 进程的状态。所有代码都应该检查到主干,不断构建和测试,并且代码库可以按需部署:所有这些都使 CD 成为现实。
TBD 导致更简单的 CD 工作流程:您不必并行构建多个分支、将分支映射到环境并在相同的功能合并到主干时重新测试。简化工作流程在微服务的上下文中非常重要,因为随着微服务数量的增加,复杂性会加剧。
功能切换是 TBD 的一项重要技术。
功能切换
功能切换允许提交正在进行的功能和已完成功能的组合。通过这些切换,您可以关闭生产中不完整功能的表现,直到这些功能在预生产环境中开发完成并经过充分测试。
这是一个非常简单的例子。该团队正在为同一应用程序开发四个功能:搜索、菜单、登录和应用内聊天。应用内聊天功能不完整(但您仍会在 TBD 中检查主干)或者您在生产前测试中发现应用内聊天存在问题。通过功能切换,您可以简单地关闭应用内聊天,即使在运行时也是如此。
[](https://res.cloudinary.com/practicaldev/image/fetch/s--dvKGKyzN--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cl.ly/ baba3926feaa/download/Image%25202019-04-04%2520at%25206.42.51%2520PM.png)
功能切换通常存储在靠近代码库的规范或配置文件中,并由 CD 管道中的自动化用于在特定环境中打开切换。它们只是代码库中的条件。您应该将这些切换设置与实际发布过程分开,以便您可以在运行时控制它。
实现功能切换时应考虑的一些事项:
功能切换应该是短暂的
一旦功能已经完成开发生命周期并在生产中启用,就应该放弃功能切换。它们被认为是需要清理的代码债务。
使用工具来管理切换的生命周期
不要低估管理这些切换所需的工作量。您可以轻松地遇到数百个。使用工具来提供对切换列表的可见性、在哪个环境中打开了什么以及在下一个版本中将在生产中打开哪些功能。
考虑构建自己的实用程序
那里没有很多工具,因此请考虑编写自己的实用程序来解决其中一些问题。同样,在您采用微服务策略之前将这些工具部署到位是明智之举。
一旦有了维护功能切换的机制,您就可以使用相同的机制来引入其他类别的切换:
[](https://res.cloudinary.com/practicaldev/image/fetch/s--xjDJvDQ5--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cl.ly /bbdfb85bfea2/download/Image%25202019-04-04%2520at%25206.43.29%2520PM.png)
这张图是从我的同事 Pete Hodgson 那里借来的,他写了很多关于切换的文章。在此图中,发布切换被定义为控制对未完成代码的访问的切换,这与功能切换相同。
Ops 切换控制生产代码的行为。具有大量季节性流量的零售站点使用 Ops 切换来在峰值负载时提供降级的体验。例如,当 Apple 发布新 iPhone 时,为了购买 iPhone 而获得大量流量,他们可以在高峰时段关闭用户推荐等功能以支持销售交易。
权限切换用于打开特权用户的特定行为,例如管理员功能,或提供来宾用户浏览体验。
实验切换用于多变量测试。它用于在您将其永久化之前测试功能的接收情况。这与 A/B 测试相同。
需要注意的一点是,这些切换类别中的每一个都有非常不同的生命周期和不同的打开和关闭方式。你需要做出相应的计划。发布切换通常更短暂,仅在几个发布期间有效。一旦该功能完全发布,您就可以摆脱切换并消除您的技术债务。操作切换经常用于生产中的功能,因此它的寿命更长。
总结
这是我们的微服务博客系列 CD 的第 3 部分。我们已经深入讨论了 CI 实践,特别是基于主干的部署和功能切换。在下一篇文章中,我们将讨论第三个考虑因素:环境策略。
更多推荐
所有评论(0)