在您职业生涯的某个时刻（如果您还没有的话），您都会参与到一个整体软件发布中。也就是说，软件发布存在顽固的错误和相互依存关系，需要整个团队全天候待命。更不用说一旦投入生产，它可能需要几个补丁。
发布代码（软件版本）是衡量软件开发人员敏捷性的强大指标。如果发布过程不顺利，那么加快规划、编码和测试速度的一切努力都是徒劳的。这就是敏捷开发团队和 DevOps 团队转向自动化、在开发阶段早期将开发和运营整合在一起、实施持续集成并立即解决缺陷的原因。
保持代码处于可发布状态是敏捷开发的标志。如果您在决定代码准备就绪时就无法发布代码，那么所有的精益规划和迭代开发都将毫无意义。
优秀的软件版本始于模块化架构
在任何软件程序中，最好轻松且频繁地发布软件。团队可以通过构建（或重构为）模块化架构，使发布成为其敏捷开发文化的一部分。与其有一个大型应用（如上面提到的整体式），不如在程序的早期将其模块化为几个部分。将相似的功能分组为较小的应用或组件，并在每个应用和组件之间建立明确的 API 合约。这些 API 可以在每个内部版本中自动进行测试，以确保兼容性并降低软件发布中的风险。
模块化架构意味着您不必在杂乱的版本中发布整个软件堆栈，而且 API 合约可以轻松更新组件并确保版本之间的兼容性。简而言之，模块化软件版本需要更少的活动部件。这转化为更简单的版本。
优秀的软件发布由良好的关系提供支持
软件开发很少是独立完成的。事实上，出色的软件开发涉及从产品管理到运营的整个团队。例如，运营团队是将软件交付到生产环境的关键合作伙伴，因为他们可以帮助最终用户使用软件。
开发团队可以通过以下技术帮助运营团队了解情况并为其提供支持：
- 明确每个软件版本的物料清单。运营团队并不总是像开发团队那样拥有同样的版本上下文信息。
- 对于发布中已解决的每个事务，请提供一个指向您的事务跟踪器和源代码控制系统的链接，以便在部署期间出现问题时，运营团队具有相同的上下文级别。
- 有时在将代码从开发环境推送到暂存环境时会出现事务。关注这些事务，因为它们可能会在生产推送期间再次出现。
- 可能会发生部署故障，因此请始终为运营团队提供明确的上报路径，以顺利解决问题。
运营团队可以通过以下建议帮助其同行进行开发：
- 当生产中出现问题时，请花点时间了解根本原因和解决方案。将来会避免（或更优雅地处理）它们。
- 将配置数据从生产环境迁移回暂存和开发环境，以防止配置偏差。
随着代码从开发迁移到暂存，再迁移到生产，关键配置和用户数据的迁移方式恰恰相反：从生产到暂存再到开发。这种双向关系有助于开发环境对生产环境进行紧密建模。这意味着发布当天的错误和意外更少。
优秀的软件发布很容易推出
自动化！自动化！自动化！
软件发布自动化是改善发布文化的最佳方式。如果当前尚未自动发布软件，请先将软件自动发布到暂存环境。一旦每个人都看到它有多简单，那么自然就会开始自动化生产部署。
如果发布比较困难，经常实践软件发布，即使只是为了暂存。让开发团队感受到发布的痛点将激发创新，使其更容易（和自动化）。
自动化测试和持续集成是推动出色发布的关键。确保构建时间和测试时间尽可能短，并记住易于验证的内部版本更容易发布。这是因为验证周期更紧密地跟随团队。
优秀的软件发布很棒！
保持代码处于可发布状态是敏捷开发的标志。
对于我们的 SaaS 资产，我们发现小规模、频繁的软件发布最容易管理。对于可下载的产品，开发、运营和构建工程团队之间的紧密协作将大有帮助。这些小组应共同努力，实现软件发布自动化，并主动调整自动化以适应即将到来的产品变更。Atlassian 的许多团队都会自动将每个成功的主要内部版本部署到测试环境中。如果需要将软件版本提升为暂存版本或将其发布给客户，这些团队只需按一下按钮即可触发部署自动化。
作为软件开发人员，软件发布应该是我们创新周期的亮点。我们可以看到客户与我们编写的代码进行交互并提供反馈。好极了！让发布成为您工作的一部分，从而更轻松地将代码发布到生产环境中，并满意地说：“那是我的代码！”
免费开始使用 DevOps 项目计划模板
使用开放式工具方法来开发、部署和管理应用。
