无压力的软件发布之旅

无压力的软件发布之旅

认真看完这段视频，保证你在下一次大发布以前不会再有那么大压力。

最能衡量敏捷团队成功的标准就是将可用的软件发布给客户。可是，即便是有经验的软件团队也会感到十分痛苦，由于这也是验证已经完成的问题了；代码没有通过评审，代码还没来得及合并，或者合并代码失败。听起来是否是很熟悉啊？

「CODING 企业版」做为企业级软件研发管理系统，助力团队敏捷开发转型升级。

在这个演示中，你将学习到下面几点：

• 编码最佳实践，将提升你交付高质量产品的能力。了解为何代码评审对于交付质量是相当重要的，而且监视和修复失败的构建能保证发布更快捷。

• 经过在发布中心创建清晰的图表来表示发布的进度和状态，你会学习如何节省工做时间。

• 从构建、编码到发布的彻底自动化。经过从发布中心直接发布你的版原本简化工做流程。

观看 & 学习

提问和回答

咱们的主持人 Jason Wong 和 Megan Cook 从此次演讲中选择了他们最喜欢的问答。继续阅读以了解更多关于无压力发布的信息。

问题 1：成功使用发布中心的 3 个最重要的非技术因素是什么？

回答 1：（1）充满信心地交付：团队内外的利益相关者将可以知道在整个发布周期的任什么时候候都应该准备好什么。
（2）更快地作出决策以节约时间：准备好交付，及时了解已经完成了哪些功能，以及还存在哪些有问题。在发布中心中跟踪检查本次发布版本的全部问题，这样你就没必要手动协调问题解决和调整代码了。
（3）发布的记录：经过查看已发布的版原本了解发布什么特性（什么时候发布），以及经过查看未发布的版本，了解每一个即将发布的版本的计划。

「CODING 企业版」提供便捷的发布管理，清晰每一次发布交付物，方便运维团队执行开发团队的发布计划。

问题2：在 Atlassian 中，一般是谁来管理版本发布？

回答2：Atlassian 中每一个团队都有它本身的特定方法，但总的来讲，咱们尽量的将过程自动化，以便以最少的开销修复 bug。
团队一般有一份待完成事项的列表，可是咱们尽可能将其最小化。像发布中心这样的工具在这个过程当中帮助确保咱们计划发布的是最高质量的，而且 Jira 软件问题的状态和它们的实际开发很是匹配。
一些较大的团队对于 bug 管理者/发布管理者会创建专人轮换制度。
对于较大的主版本和小版本，一般会有一个专门的人来负责发布，而且全部的工做都是围绕风险和时间期限展开的。这可能由团队领导或开发经理负责，可是咱们试图确保由团队成员轮换负责，这样每一个人都知道这个过程，并理解发布高质量软件的要求。

对于发布的计划时间线，团队领导将与产品经理和市场营销人员进行协调，以肯定什么时候准备好发布，以及是否须要管理发布范围或时间。正是由这些人，决定了哪些功能将在哪些版本中发布。

问题3：你如何作到一个分支/提交/合并请求/构建/部署关联到一个问题（issue）？

回答3：

1. 分支——在分支名称中包含指定问题的标记，也就是 issue 的 key 。
2. 提交——在提交消息中包含 issue key。
3. 合并请求——在源分支名称中，或者提交消息，或合并请求标题中包含 issue key。
4. 构建——在提交消息中包含 issue key。
5. 部署——在提交消息中包含 issue key。

问题4：当你在隔离的多个分支上使用相同的代码时，你有什么经验来处理这些冲突？

回答4：咱们的经验是，这不多是一个问题。大多数状况下不存在代码重复，只是偶尔会发生冲突。
一般会有两个问题：

• 长期运行的特性分支与其余正在进行的开发隔离。
• 大规模的重构任务，在完成、测试并准备发布以前，须要隔离。

对于前者，一种作法是频繁地进行开发和集成，可是将特性自己保留在特征标志后面，这样只有咱们本身的测试程序或少数几个客户能看到正在进行的更改。这确保了相互冲突的代码不断地集成，最小化冲突的可能性，并在大特性更新到主干开发分支时最小化风险和影响。

若是作不到这样，或者在进行大型重构的状况下，咱们确保开发分支尽量多地集成到特性分支中（经过将基线/开发分支的变动合并到特性分支中）。这确保了全部正在进行的开发都是在长时间运行的特性分支上完成的，而且尽量常常地进行测试。若是存在任何合并冲突，那么就更容易让作更改的人来帮助解决合并冲突，或者至少保持他们影响范围最小化，这样解决起来就更容易点。

最好的解决方案是将任何工做分解成块，以便尽量频繁地合并到稳定或开发分支中。这就减小了在特性分支中对相同文件进行更改的机会。

问题5：你建议用什么样的策略来管理正在进行的开发分支、热修复分支和部署到不一样环境的分支（测试环境/定版环境/生产环境）等并行分支？

回答5：在咱们的网站上有许多分支策略，着重看下比较工做流部分。

在之前的一些讨论中能够找到更多的细节，正确使用 Git 和持续的部署工做流程在 SaaS 团队的 Git 工做流中有更深刻的介绍。
简而言之，有两种主要的工做流：可下载产品的产品发布工做流和在线服务的 SAAS 工做流（ SAAS 团队的 Git 工做流）。

「CODING 企业版」做为企业级软件研发管理系统，任务看板功能实现了 Epic  user stories  Sprint 等敏捷概念落地。

对于可下载的产品，大多数团队使用的是 Gitflow 工做流的变体，其中主线用于正在进行的开发，而以前的每个小版本都有本身的分支，其中 bugfix 分支建立了而后再合并回来，在须要的时候，就构建一个 Bug 修复版本。以前的每一个发布分支都将全部的变动合并到后续版本中，并确保全部的 Bug 修复都包含在全部后续版本中。

问题6：发布中心是否能很好地与看板和频繁发布协同工做？

回答6：是的，它工做得很好。看板上的发布按钮能够用来建立一个新版本，其中包含了该版本的全部问题。一旦建立了这个版本，就可使用发布中心检查任何警告，或者得到版本的概述。
即便没有看板图，你也能够在任什么时候候建立一个版本，并在这些问题已经完成的状况下添加问题。而后，发布中心能够用来检查任何警告，以确保发布已经准备稳当。

问题7：发布中心是否能够显示来自多个 Jira 软件项目的问题信息，或者是发布中心项目和修复版本？

回答7：发布中心是一个版本的详细视图。因为版本目前是针对特定项目的，因此发布中心也是针对特定项目的。

问题8：你能让发布中心的警告自动发布到一个 Hipchat 聊天室里吗？

回答8：到今天为止，发布中心警告和 Hipchat 之间没有集成，咱们目前尚未任何计划去集成。咱们一直在思考发布中心能够经过不一样的方式增强与 Hipchat 的团队协做，并但愿从咱们的客户那里听到更多关于他们如何使用这种集成或与其余产品的集成的更多信息。

问题9：“发布”按钮后面关联的是什么？是用来部署生产服务器的脚本吗，好比 Bamboo 中的 Job ？

回答9：“发布”按钮有一些与之相关的功能：

• 它能够设定发布日期，并将版本的状态更改成“已发布”。若是在版本中有任何开放的问题，它也会提供将这些问题转移到另外一个版本的选项。这些均可以在没有 Bamboo 的状况下使用。

• 当 Bamboo 与 Jira 软件集成时，发布按钮能够用来启动一个新的构建，能够用 Bamboo 来配置，以采起必要的步骤来发布你的版本（例如，部署到生产环境的脚本）。

• 发布按钮也可用于启动已运行的 Bamboo 构建的手动定版发布。你能够拥有一个自动运行的构建，可是有一个可选的阶段，只有手动触发，才能实际执行部署/放行。（这个阶段至关于选项2中的整个构建，可是能够经过人工操做来触发构建。）

问题10：是否有将发布中心与 GitHub/GitHub 企业版整合的计划？
回答10：发布中心已经与 GitHub 和GitHub 企业版合做。你所要作的就是将 Jira 软件实例链接到你的 GitHub 账号，使用 DVCS 帐户在 Jira 软件的附加管理员菜单中能够找到。而后你就能够开始跟踪全部版本的进展，包含了发布中心中全部相关开发信息。

「CODING 企业版」提供便捷的发布管理，清晰每一次发布交付物，方便运维团队执行开发团队的发布计划。

本文中文翻译自原文：Journey to a stress-free release 编译者：程景天。