一份良好架构加上两份团队合作。再加点儿自动化,然后搅拌就好了。
在你的职业生涯中,你一定会参与到一个庞大的软件发布中。这个软件发布可能带有各种顽固 Bug 和复杂依赖关系,它需要整个团队全天候工作。更不用提的是,一旦它投入生产,它还需要不停地打补丁。
「CODING 企业版」作为企业级软件研发管理系统,助力团队敏捷开发转型升级。
代码发布是软件开发人员敏捷性的一个强有力的晴雨表。如果发布过程不顺畅,那么每一次制定计划、编程和测试的努力都是徒劳的。为了使发布过程敏捷,部署自动化是关键。在开发阶段早期就要将程序员和运维人员聚集在一起,进行持续集成和快速解决缺陷的练习。
将代码保持在可发布状态是敏捷开发的标志。如果你在定下来要发布时却发布不出来代码,那么世界上所有的精益计划和迭代开发都毫无意义。
在所有软件项目中,最好的情况是可以频繁且顺畅地发布版本。通过构建(或重构)模块化架构,团队可以使发布成为他们敏捷文化的自然组成部分。在项目的早期,还不会有一个大的应用程序(如上面提到的庞然大物),就应该将其按模块化切分。将类似的特性分组到较小的应用程序或组件中,并且在每个应用程序和组件之间有清晰的 API 接口。这些 API 可以在每次构建中自动测试,以确保兼容性,并降低软件发布中的风险。
模块化的体系架构意味着您不需要 “大爆炸”式地发布整个软件库,而 API 契约使组件新老版本之间的兼容变得容易。简单地说,模块化的发布只需要移动很少的组件。这可以简化发布流程。
软件开发很少在真空中完成。实际上,伟大的软件开发涉及到整个团队,从产品管理人员到运维人员。例如,运维团队是向生产交付软件的关键合作伙伴,因为他们帮助软件抵达最终用户。
开发团队可以通过这些方面助力运维团队:
为每个发布版本制作发布清单。运维团队没法总是像开发团队那样了解本次发布的具体情况。
对于在发布中解决的每个问题,提供一个问题跟踪记录和源代码版本控制的链接,这样如果在部署过程中出现问题,运维团队就可以知道问题的来龙去脉。
有时,当将代码从开发环境推到定版环境时会出现问题。把这些问题解决掉,因为它们可能会在生产过程中再次出现。
部署故障发生时,一定要给运维团队一个清晰的升级方案,以顺利地解决问题。
反过来,运维团队也可以通过如下方面帮助开发团队:
当生产中出现问题时,花点时间去理解根本原因和解决方案。这样在将来这些问题才能避免再次发生(或更优雅地处理)。将配置数据从生产环境迁移到定版环境和开发环境,以防止配置数据不同步。
随着代码从开发环境转移到发布环境,再到生产环境,关键配置和用户数据迁移的方式正好相反:从生产环境迁移到开发环境。做好这种双向同步有助于开发环境更真实地模拟生产环境。这意味着在发布日会有更少的 Bug 和“惊喜”。
「CODING 企业版」提供便捷的发布管理,清晰每一次发布交付物,方便运维团队执行开发团队的发布计划。
自动化!自动化!自动化!
自动化发布是改进发布文化的最好方法。如果今天你的发布还不是自动化的,那你可以从自动化发布到定版环境开始做起。一旦每个人都看到了它如此简单,自然的步骤就是自动化发布到生产部署。
如果你觉得发布是困难的,那就把它作为一种经常性的练习——即使只是为了定版。让开发团队感到发布的痛苦点将激发他们的创新能力,使发布更容易,更自动化。
自动化测试和持续集成是驱动成功发布的关键规程。确保构建时间和测试时间尽可能短,并且要记住易于验证的构建更容易发布。
将代码保持在可发布状态是敏捷开发的标志。
如果你不能快速发布,你所有的精益计划和迭代开发都毫无意义。
我们发现,由于我们提供的是软件即服务( SaaS ),小步快跑的发布模式是最容易管理的。对于可下载的产品,开发、运维和构建工程团队之间的紧密协作将会有很长的路要走。这些团队应该团结合作来完成自动化发布,并主动地为即将到来的产品变更调整自动化发布。Atlassian 的许多团队都将每一个成功的主线版本发布到一个测试环境中。当到交付阶段需要正式发布版本,或者发布给客户时,这些团队只需要按下按钮,触发自动化部署就可以了。
「CODING 企业版」作为企业级软件研发管理系统,任务看板功能实现了 Epic \ user stories \ Sprint 等敏捷概念落地。
作为软件开发人员,发布应该是我们创新周期的重点。通过发布,我们可以看到客户与我们编写的代码进行交互,并提供反馈。耶!让发布成为你工作日的一个自然部分,当代码从指间流淌出来,你会享受着这样的满足感:“这是我的代码!”
本文中文翻译自原文:Three ingredients for great software releases 编译者:程景天。