大家好！ 朋友们，在冬天的最后一天，我们将在
“ DevOps实践和工具”课程上推出新的课程。 预期课程的开始，我们将与您分享文章的第一部分：“ CI / CD模式和反模式”。
部署管道任务包括三个部分：
- 可见性：供应链的所有方面（创建，部署，测试和发布）对于团队成员都是可见的，并可以促进协作。
- 反馈：团队成员尽快发现问题，以便尽快解决。
- 连续部署：使用全自动过程，您可以在任何环境中部署和发布任何版本的软件。
在上面的“部署管道”图中，所有模式都有上下文。 有些模式涵盖了该管道的多个阶段，因此我选择了最常使用它们的阶段。
1.1配置管理-模式和反模式1.1.1自定义第三方软件- 模式：评估和使用可以轻松配置，部署和自动化的第三方软件。
- 反模式：不能在外部配置的软件。 没有要求命令才能使用GUI的API或命令行界面的软件。
1.1.2配置目录- 模式：支持每个应用程序的所有参数的目录，更改这些参数的方式以及每个应用程序的存储位置。 自动目录创建是构建过程的一部分。
- 反模式：未记录配置参数。 所有应用程序和其他资产的目录都是本地的，难以描述的“民俗”。
1.1.3主线- 模式：减少合并，通过在主线工作来控制活动代码行的数量。
- 反模式：每个项目有多个分支。
1.1.4每日合并- 模式：在主线中进行的更改至少每天都应用于所有分支。
- 反模式：每周或每天少于一次合并所有迭代。
1.1.5安全配置- 模式：配置信息存储在安全，可远程访问的位置，例如数据库，目录或注册表中。
- 反模式：打开文本密码和/或一台计算机或共享资源。
1.1.6仓库- 模式：所有源文件（可执行代码，配置，主机环境，数据）都通过版本控制上载到存储库。
- 反模式：某些文件已压缩，而其他文件（例如，环境配置或数据更改）未压缩。 检入可以在构建或部署过程中重新创建的二进制文件。
1.1.7短期分支机构- 模式：分支应该短暂存在，理想情况下，应保留几天，且迭代不超过一次。
- 反模式：分支的生存期超过迭代。 产品功能的分支，发布后仍存在。
1.1.8团队环境- 模式：使用版本控制检出项目存储库，并运行一个命令来构建应用程序并将其部署到任何可用环境中，包括本地开发。
- 反模式：要求开发人员定义和配置环境变量。 迫使开发人员安装许多构建/部署工具。
1.1.9一种操作方式- 模式：管理整个系统的配置-源，配置，环境，数据。 任何更改都可以跟踪到版本控制系统中的特定修订版。
- 反模式：系统的某些部分没有版本。 无法回滚到以前的系统软件设置。
1.2 CI持续集成-模式和反模式1.2.1构建阈值- 模式：违反项目规则时，程序集将崩溃。 例如，违反体系结构，测试缓慢，违反代码编写标准。
- 反模式：手动检查代码。 在开发周期的后期阶段检测代码质量问题。
1.2.2频繁提交- 模式：每位团队成员都要定期检入-至少每天一次，但最好在完成CI系统的每项任务之后。
- 反模式：由于开发人员进行的更改数量众多，因此每天提交源文件的频率少于每天一次。
1.2.3持续反馈- 模式：从CI系统向跨职能团队的所有成员发送自动反馈。
- 反模式：不发送通知； 通知被忽略； CI系统会将信息发送给每个无法使用的人。
1.2.4持续集成- 模式：在使用版本控制对项目存储库进行任何更改之后，将进行软件组装和测试。
- 反模式：预定程序集，夜间程序集，定期程序集，仅在开发人员机器上的程序集，完全没有程序集。
1.2.5“停线”原则- 模式：尽快修复所有软件交付错误； “停下来”。 没有人签入损坏的组件，因为修复它的优先级最高。
- 反模式：程序集长期处于损坏状态，从而阻止开发人员检查工作代码。
1.2.6独立大会- 模式：编写与IDE分开的构建脚本。 这些脚本由CI系统执行，因此每次更改都会执行组装。
- 反模式：自动构建取决于IDE配置。 无法从命令行启动程序集。
1.2.7可见仪表板- 模式：可以查看有关交付系统的所有信息。 提供高质量的实时跨职能团队反馈。
- 反模式：警报仅通过电子邮件发出。 反馈未发布给整个团队。
第一部分结束。
这是这种材料。 您可以在
此处阅读翻译的续篇，现在我们正在等待您的评论，我们邀请您参加将于今晚举行
的公开网络研讨会 。