优秀软件版本的三个要素

将一部分架构与两部分团队合作相结合。添加自动化,然后混合。

Dan Radigan 作者:Dan Radigan
浏览主题

在您职业生涯的某个时刻(如果您还没有的话),您都会参与到一个整体软件发布中。也就是说,软件发布存在顽固的错误和相互依存关系,需要整个团队全天候待命。更不用说一旦投入生产,它可能需要几个补丁。

发布代码(软件版本)是衡量软件开发人员敏捷性的强大指标。如果发布过程不顺利,那么加快规划、编码和测试速度的一切努力都是徒劳的。这就是敏捷开发团队和 DevOps 团队转向自动化、在开发阶段早期将开发和运营整合在一起、实施持续集成并立即解决缺陷的原因。

保持代码处于可发布状态是敏捷开发的标志。如果您在决定代码准备就绪时就无法发布代码,那么所有的精益规划和迭代开发都将毫无意义。

优秀的软件版本始于模块化架构

在任何软件程序中,最好轻松且频繁地发布软件。团队可以通过构建(或重构为)模块化架构,使发布成为其敏捷开发文化的一部分。与其有一个大型应用(如上面提到的整体式),不如在程序的早期将其模块化为几个部分。将相似的功能分组为较小的应用或组件,并在每个应用和组件之间建立明确的 API 合约。这些 API 可以在每个内部版本中自动进行测试,以确保兼容性并降低软件发布中的风险。

模块化架构意味着您不必在杂乱的版本中发布整个软件堆栈,而且 API 合约可以轻松更新组件并确保版本之间的兼容性。简而言之,模块化软件版本需要更少的活动部件。这转化为更简单的版本。

优秀的软件发布由良好的关系提供支持

软件开发很少是独立完成的。事实上,出色的软件开发涉及从产品管理到运营的整个团队。例如,运营团队是将软件交付到生产环境的关键合作伙伴,因为他们可以帮助最终用户使用软件。

开发团队可以通过以下技术帮助运营团队了解情况并为其提供支持:

  • 明确每个软件版本的物料清单。运营团队并不总是像开发团队那样拥有同样的版本上下文信息。
  • 对于发布中已解决的每个事务,请提供一个指向您的事务跟踪器和源代码控制系统的链接,以便在部署期间出现问题时,运营团队具有相同的上下文级别。
  • 有时在将代码从开发环境推送到暂存环境时会出现事务。关注这些事务,因为它们可能会在生产推送期间再次出现。
  • 可能会发生部署故障,因此请始终为运营团队提供明确的上报路径,以顺利解决问题。

运营团队可以通过以下建议帮助其同行进行开发:

  • 当生产中出现问题时,请花点时间了解根本原因和解决方案。将来会避免(或更优雅地处理)它们。
  • 将配置数据从生产环境迁移回暂存和开发环境,以防止配置偏差。

随着代码从开发迁移到暂存,再迁移到生产,关键配置和用户数据的迁移方式恰恰相反:从生产到暂存再到开发。这种双向关系有助于开发环境对生产环境进行紧密建模。这意味着发布当天的错误和意外更少。

优秀的软件发布 | Atlassian 敏捷教练

优秀的软件发布很容易推出

自动化!自动化!自动化!

软件发布自动化是改善发布文化的最佳方式。如果当前尚未自动发布软件,请先将软件自动发布到暂存环境。一旦每个人都看到它有多简单,那么自然就会开始自动化生产部署。

如果发布比较困难,经常实践软件发布,即使只是为了暂存。让开发团队感受到发布的痛点将激发创新,使其更容易(和自动化)。

自动化测试和持续集成是推动出色发布的关键。确保构建时间和测试时间尽可能短,并记住易于验证的内部版本更容易发布。这是因为验证周期更紧密地跟随团队。

优秀的软件发布很棒!

保持代码处于可发布状态是敏捷开发的标志。

我们是怎么做的

对于我们的 SaaS 资产,我们发现小规模、频繁的软件发布最容易管理。对于可下载的产品,开发、运营和构建工程团队之间的紧密协作将大有帮助。这些小组应共同努力,实现软件发布自动化,并主动调整自动化以适应即将到来的产品变更。Atlassian 的许多团队都会自动将每个成功的主要内部版本部署到测试环境中。如果需要将软件版本提升为暂存版本或将其发布给客户,这些团队只需按一下按钮即可触发部署自动化。

作为软件开发人员,软件发布应该是我们创新周期的亮点。我们可以看到客户与我们编写的代码进行交互并提供反馈。好极了!让发布成为您工作的一部分,从而更轻松地将代码发布到生产环境中,并满意地说:“那是我的代码!”

An infinity symbol.

Get started free with the DevOps project plan template

Develop, deploy, and manage applications with an open tools approach.

后续内容
无压力发布