了解有关选择发布管理工具的注意事项
在选择正确的发布管理工具时，应了解所有不同组件的可能性，并将它们与你的需求相匹配。
市场中提供了许多工具，我们将在下一章中进行探讨。 要注意的最重要的一点就是，并非每个供应商或工具在发布管理方面的处理方式都类似。
市场中的工具可以分为两类。
- 可以执行生成、持续集成和部署的工具。
- 可以完成发布管理的工具。
在许多情况下，公司只需要发布管理的部署部分。
许多生成或发布工具都可以执行部署或安装。 主要是因为发布的技术方面是执行脚本或运行程序，而需要审批、质量检验关和不同阶段的发布管理需要一种不同的工具，与生成和 CI 工具紧密集成的工具是不一样的。
项目和项目源
项目可以来自不同的源。 将项目视为版本控制包时，需要在发布管道使用项目之前将项目存储在某处。 选择工具的注意事项：
- 支持哪些源代码管理系统？
- 发布管道中能否有一个或多个项目源？ 换句话说，可以将不同源中的项目合并到一个发布中吗？
- 它是否与生成服务器集成？
- 它是否支持其他生成服务器？
- 它是否支持容器注册表？
- 如何保护与项目源的连接？
- 可以扩展项目源吗？
触发器和计划
触发器是管道中的基本组件。 启动发布需要触发器，但如果想要有多个阶段，可以创建部署。 选择触发器的注意事项：
- 系统是否支持持续部署触发器？
- 能否从 API 触发发布（用于与其他工具集成）？
- 可以计划发布吗？
- 可以单独计划和触发每个阶段吗？
审批和入口
使用脚本、可执行文件或可部署项目启动发布不会区分持续集成/生成工具和发布管理工具。 将发布审批工作流添加到管道是产生不同效果的关键组件。 有关审批的注意事项：
- 是否需要审批发布管道？
- 审批者是否属于你的公司？ 他们是否需要工具许可证？
- 想要使用手动审批还是自动审批？ 或者访问这两种应用程序？
- 能否审批 API（与其他工具集成）
- 能否与审批者一起设置工作流（可选和必需）？
- 每个阶段的审批者能否不同？
- 可以有多个审批者吗？ 是否需要审批者全部审批？
- 自动审批的可能性是什么？
- 能否在发布管道中手动审批或手动执行步骤？
阶段
运行生成和部署产品的持续集成管道是一种常用的方案。 但是如果你想将同一个发布部署到不同的环境中呢？ 在选择正确的发布管理工具时，在涉及到阶段（或环境）时，你应该考虑以下问题
- 可以使用同一项目部署到不同的阶段吗？
- 能否在各阶段之间进行不同的配置？
- 可以针对每个阶段使用不同的步骤吗？
- 能否跟踪阶段之间的发布？
- 能否跟踪阶段之间的项目/工作项和源代码？
生成和发布应用。
最后，需要在管道中完成工作。 不仅与工作流和业务流程相关，还必须部署或安装代码。 任务执行时要考虑的问题。
- 如何创建步骤？ 是运行一个脚本（bat、shell、PowerShell CLI），还是有专门的任务？
- 能否创建任务？
- 任务如何进行验证以确保源的安全？
- 任务能否在多个平台上运行？
- 任务可以易于重用吗？
- 能否与多个环境集成？ （Linux、Windows、容器群集、PaaS、云）
- 能否控制管道中使用的任务？
可跟踪性、可审核性和安全性
在需要遵守合规性框架的企业和公司中，其中一个基本要素是：
- 可跟踪性。
- 可审核性。
- 安全性。
尽管这一点与发布管道没有明确的关系，但很重要。
就符合性来说，有三项原则至关重要：
- 四眼原则
- 至少还有另一个人员查看已部署的项目吗？
- 部署另一个人员的是编写代码的人员吗？
- 可追溯性
- 能否查看已发布软件的来源（代码）？
- 能否查看导致此更改的要求？
- 能否通过代码、生成和发布遵循要求？
- 可审核性
- 能否查看谁、何时以及为何更改了发布过程？
- 能否查看谁、何时以及为何部署了新发布？
安全性至关重要。 当用户可以执行所有操作（包括删除证据）时，这是不可行的。 设置适当的角色、权限和授权对于保护系统和管道至关重要。
在确定合适的发布管理工具时，可以考虑以下项：
- 它是否能与公司的 Active Directory 集成？
- 可以设置角色和权限吗？
- 发布管道本身是否有更改历史记录？
- 能否确保项目在发布期间没有变化？
- 能否将要求链接到发布？
- 能否将源代码更改链接到发布管道？
- 能否强制执行审批或四眼原则？
- 能否查看发布历史记录和触发发布的人员？