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