自动部署 管道 ci cd

当我加入WorkSafeBC负责云运营和工程流程精简的云运营团队时，我实现了我的梦想，希望拥有一个仪器化管道，并为每个产品进行一次持续集成并持续交付。

根据Lukas Klose的说法， （在软件工程范围内）是“系统以稳定且可预测的速度产生价值的状态。” 我认为这是最大的挑战和机遇之一，尤其是在紧急解决方案的复杂领域。 力求通过持续，高效和优质的解决方案，提供连续不断的交付模式，构建正确的事物并让我们的用户感到满意。 寻找方法将我们的系统分解成对自己有价值的较小部分，使团队能够逐步交付价值。 这需要改变业务和工程设计的思维方式。

持续集成和交付（CI / CD）流程

CI / CD管道是DevOps的一种实践，用于更频繁，一致和可靠地交付代码更改。 它使敏捷团队能够提高部署频率并减少变更的前置时间 ， 变更失败率以及恢复关键绩效指标（KPI）的平均时间 ，从而提高质量并更快地交付价值 。 唯一的先决条件是扎实的开发流程，从构思到弃用的功能质量观念和责任心，以及全面的流程（如下所示）。

它简化了工程流程和产品，以稳定基础架构环境； 优化流程； 并创建一致，可重复和自动化的任务。 正如Dave Snowden的模型所概述的那样，这使我们能够将复杂的任务转变为复杂的任务，从而降低了维护成本并提高了质量和可靠性。

精简流程的一部分是将 Muri（超负荷），Mura（变异）和Muda（废物）最小化。

• Muri：避免过度设计，与业务价值不相关的功能以及过多的文档
• Mura：改进批准和确认流程（例如，安全签名）； 推动计划推动单元测试，安全漏洞扫描和代码质量检查； 并改善风险评估
• Muda：避免浪费技术债务，错误和前期详细文档

看起来80％的重点和意图都放在提供集成和协作工程系统的产品上，这些系统可以采用想法并计划，开发，测试和监视您的解决方案。 但是，成功的改造和工程系统仅占产品的5％，有关过程的15％和有关人员的80％。

有许多产品可供我们使用。 例如，Azure DevOps为持续集成（CI），持续交付（CD），可扩展性以及与开源和商业现货（COTS）软件即服务（SaaS）解决方案（例如Stryker， SonarQube，WhiteSource，Jenkins和Octopus。 对于工程师而言，专注于产品始终是一种诱惑，但请记住，它们只是我们旅程的5％。

最大的挑战是基于数十年的规则，法规和令人沮丧的舒适区域来分解一个过程：“ 这是我们一直以来所做的；为什么要改变？ ”

开发和运营中人与人之间的摩擦导致各种支离破碎，重复的，不间断的集成和交付管道。 开发需要访问所有内容，以进行连续迭代，以使用户能够使用，并可以持续快速地进行发布。 运营部门希望锁定一切以保护业务和用户并提高质量。 这在无意间并经常导致难以自动化的流程和治理，从而导致发布周期慢于预期。

让我们用最近的白板讨论中的摘录探索管道。

管道的变化难以支撑且成本高昂； 版本控制和可追溯性的不一致使现场事件更加复杂，开发流程和管道的不断精简是一个挑战。

我主张一些原则，以使每个产品具有一个通用管道：

• 使一切自动化
• 建立一次
• 保持持续集成和交付
• 保持持续精简和改进
• 维护一个构建定义
• 维护一个发布管道定义
• 尽早并经常扫描漏洞，然后快速失败
• 尽早进行测试，并且经常失败
• 保持发布的可追溯性和可观察性

但是，如果我戳大黄蜂的巢，最重要的原则就是保持简单 。 如果您无法解释管道的原因（ 什么 ， 为什么 ）和过程（ 如何 ），则您将无法理解您的工程过程。 我们大多数人都不在寻找最好的，超现代的和革命性的管道，我们需要一个功能强大，有价值并能推动工程的管道。 首先应对80％的人群-文化，人员和思想观念。 让您的CI / CD骑士身着闪亮的盔甲，并在盾牌上贴上TLA（两个/三个字母的缩写）符号，以加入实践和经验工程的力量。

统一管道

让我们逐步完成我们的一项设计实践白板会议。

使用每个应用程序一个构建定义来定义一个CI / CD管道，该定义用于触发请求合并前的合并请求和持续集成构建。 生成包含调试信息的发行版本，并将其上传到 。 这使开发人员可以在生产环境中进行本地和远程调试，而不必担心他们需要加载哪个内部版本和符号-符号服务器为我们执行了这一魔术。

在构建中执行尽可能多的验证（ 向左移动），以允许功能团队快速失败，不断提高整体产品质量，并在每次拉动请求时为审阅者提供宝贵的证据。 您是否喜欢带有大量提交的请求请求？ 还是带有几个提交和支持证据（例如安全漏洞，测试范围，代码质量和突变体残迹）的请求请求？ 我个人赞成后者。

不要使用构建转换来生成多个特定于环境的构建。 创建一个构建并执行发布时转换 ， 令牌化和/或XML / JSON 值替换 。 换句话说， 右移特定于环境的配置。

安全地存储发布配置数据，并根据数据的信任级别和敏感性将其提供给Dev和Ops团队。 使用开源密钥管理器，Azure密钥保险库，AWS密钥管理服务或许多其他产品之一-请记住，您的工具包中有很多锤子！

使用组代替用户将批准管理从多个管道的多个阶段转移到简单的组成员身份。

与其复制管道以使团队可以访问其感兴趣的区域，不如创建一个管道并授予对交付环境的特定阶段的访问权限。

最后但并非最不重要的一点是，接受拉取请求，以帮助提高对代码库的洞察力和透明度，提高整体质量，进行协作，并将预验证版本发布到选定的环境中； 例如开发环境。

这是整个白板草图的更正式视图。

那么，您对CI / CD管道有什么想法和经验？ 我的梦想是用一条管道统治所有的梦想吗？

翻译自:

自动部署 管道 ci cd