无压力的软件发布之旅

无压力的软件发布之旅

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

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

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

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

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

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

• 从构建、编码到发布的完全自动化。通过从发布中心直接发布你的版本来简化工作流程。

观看 & 学习

提问和回答

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

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

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

image

「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 任务看板

「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
编译者：程景天。