指南：小型团队的软件发布管理

正式化发布管理流程（如果有的话）

在某些团队配置中，尤其是在初创公司中发现的团队配置中，没有 DevOps 或基础架构工程师在发布产品的新版本时提供支持。

此外，与具有明确正式流程的大型官僚公司不同，初创公司的 CTO 或软件开发团队负责人通常不了解软件发布管理流程的复杂性； 公司中的少数开发人员可能知道该过程的复杂细节，但不是所有人。 如果这些知识没有被彻底记录下来，我相信它可能会导致混乱。

在本文中，我将尝试提供一些关于如何规范发布过程的技巧，尤其是从开发人员的角度来看。

输入软件发布清单

根据 Atul Gawande 的书Checklist Manifesto ，您可能熟悉某些操作的清单的概念。 我相信正式的发布过程（就像软件开发世界中的许多其他任务一样）为开发人员提供了实施该协议的机会。 发布过程清单应保存在共享文档中，最好以协作 wiki 或 Google Drive 上的电子表格的形式保存。

通过与团队共享此重要文档并授予编辑权限，每个成员都可以访问正式定义的发布流程。 这使他们能够了解该过程是如何工作的。 此外，在与其他团队成员讨论之后，它使团队能够不时地对其进行改进。 这应该带来透明度，并允许整个团队实时访问发布期间发生的事情、已完成的步骤以及由谁完成。

通过查看此电子表格，利益相关者可以根据步骤的结果来决定“去”还是“不去”。 例如，如果测试环境中的压力测试出错，项目经理可能会根据事件决定取消生产版本。

用作基础的建议步骤

在本节中，我将提出一些步骤，您可以使用这些步骤为您的发布过程构建您自己的清单。 其中一些步骤绝不是强制性的。 每个应用程序都不同，每个组织的工作方式也不同，因此请随意调整并做出更适合您的工作流程的更改。

1.创建发布分支

您可能熟悉 Git Workflow 的概念，或者熟悉发布分支的概念，这个主题已在之前的博文中解释过。

理想情况下，您应该至少有三个分支：

• master ：这应该反映生产环境中的当前状态。 master上的每个新提交都应该只包含一个新版本。
• 开发：这个分支应该包含已完成（和测试）即将推出的功能。 通常为每个功能创建一个单独的分支，然后在功能准备好时将其合并以进行开发。
• release ：发布分支是准备发送到生产环境的提交的集合，以及与发布相关的一些额外的小错误修复。

请注意，发布完成后应该删除发布分支，因此这些分支一直被创建和销毁，与master或develop不同，它们总是相同的。

为了创建一个新的发布分支，在你的 git 终端的开发分支中，输入：

$ git checkout -b release/xyz

使用命名约定很方便，例如上面定义的命名约定，根据您的需要将 xyz 替换为 major.minor.patch 版本号（这是您应该在团队中定义并坚持的策略）。

同样重要的是，如果您将一些错误修复编码到发布分支中，您不应该忘记将它们合并回develop 。 发布分支的主要目的是预览应用程序在投入生产后的行为方式。

2.凹凸版

下一步是在发布分支上增加（修改或增加）版本号。

您应该打开 AndroidManifest.xml / package.json / pom.xml / 或应用程序版本存储在项目中的任何位置 (YMMV)，更新版本号，然后将更改提交到当前发布分支。

出于两个原因，更新版本号很重要。

首先，您可以跟踪和映射每个版本中引入的功能，其次，如果他们需要进行一些故障排除或联系您寻求支持，您将了解他们正在使用的版本。 如果你正在构建一个移动应用程序，你在这一步更新的版本号通常会显示在用户端，在关于部分或者在Google Play或Apple App Store中。这一步也是一个更新环境依赖的好机会- 配置文件（尽管我建议将它们保存在单独的存储库中），例如将分支指向生产数据库，或构建过程所需的任何其他调整。

最后，建议您将发布分支推送到 origin，以便您的其他开发人员可以使用它：

$ git push -u origin release/xyz

3a。 将发布分支合并到 master 并标记它

只有master分支应该部署到生产环境中，因此在这一步中，我们需要将发布分支合并到master中。

 $ git checkout master $ git merge --no-ff release/xyz $ git push

--no-ff标志是可选的，但是，建议使用它以强制创建新的提交对象，即使可以使用快进技术完成合并。

接下来，是时候在master分支上标记发布了：

$ git tag -a xyz -m 'description of new version, features or fixes included'

标签很有用，因为您在 git 存储库中保留了历史中的这个特定点，您可以稍后再回来从特定标签重新创建一个单独的分支。

3b。 使用拉取请求合并发布分支

另一种经常使用的替代方法是使用拉取请求将发布分支合并到master中。

这种方法有很多优点。 为协作创建了一个新空间，团队可以使用它来讨论各种与发布相关的问题。 此时是为合并代码审查过程添加额外入口的好时机，同时有更多的眼球来监控将要引入的代码，并讨论潜在的修改。

GitHub、Bitbucket 和 GitLab 是一些允许您在工作流程中实现拉取请求的工具（合并请求，因为他们在后者上调用它）。 使用这些工具，您无需手动键入 git 命令，而是使用 Web 界面设置源分支 ( release ) 和目标分支 ( master )，然后添加一个或多个审阅者，所有审阅者都会能够对这些新变化写内联评论，提出改进建议等。

在所有审阅者批准拉取请求后，您可以通过按 UI 上的按钮自动将更改合并到master中。

4. 将Master部署到生产环境

在此阶段，最好让团队中的测试人员在部署应用程序之前进行冒烟测试（这可以在单独的检查表中定义）。 一个好的建议是将主分支部署到单独的测试环境中。 然后，测试人员可以执行一些基本操作，以确保在最新版本合并后没有出现任何问题。 如何进行冒烟测试超出了本文的范围，但您可以在网上找到很多关于它的资料。 冒烟测试的结果可以集成到发布清单/电子表格中，记录任何出错的地方。

此时，您已准备好部署更改并使其生效。 继续部署主分支。 此步骤将取决于您使用的基础架构堆栈。 它可能涉及连接到您的 Amazon EC2 实例以上传您的应用程序，或推送到 Heroku 远程，或通过 ssh 连接到您的 VPS 以复制新版本，或任何其他过程。

上传应用程序后，确保它已成功部署并按预期工作。

5. 合并回开发和删除发布分支

现在发布几乎完成了，您需要将发布分支合并到开发中，以更新后者的版本号并将所有错误修复转移到主开发分支：

 $ git checkout develop $ git merge release/xyz

现在是时候删除发布分支了：

$ git branch -d release/xyz

6. 变更日志生成

在项目的根目录下应该有一个名为 CHANGELOG.md（或等效文件）的文件，每当有新版本时，您都应该在其中添加一个新条目，以记录其中包含的所有内容，例如错误修复、新功能、已知问题，以及发行说明形式的任何其他相关信息。 这对于用户和贡献者查看项目的每个版本（或版本）之间进行了哪些更改非常有用。

变更日志条目包括日期、版本号和有关发布的一些注释。 条目应按时间倒序排列。 这是我一直在使用的一个简单模板，您可以根据自己的项目进行调整：

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

此外，这一步可以通过编写一个遍历 git log 并自动生成 changelog 条目的基本脚本来完全自动化，也可以通过使用执行相同操作的工具来实现，例如：

• Github Changelog 生成器，由 skywinder 提供，
• fojuth 的 ReadmeGen
• github-changes，作者 lalitkapoor

但请记住，您获得的自动化程度与提交消息格式的严格程度成正比。 我相信与团队就提交消息的特定格式达成一致始终是一种好习惯。 通过遵循有关提交消息样式的准则，它们将更容易解析，因此您更有可能能够自动生成更改日志。

7. 与利益相关者沟通

这是您通常会执行以下操作的地方：

• 通过内部消息传递工具（例如：Slack）让团队知道新版本已经完成。 我建议创建一个新频道（即： #releases ），其唯一目的是传达与发布相关的事件。 在采取行动后，很容易在 Slack 频道中添加挂钩以发布消息。
• 或者，向利益相关者发送一封电子邮件，其中包含指向更改日志或附加更改日志文件的链接。
• 写一篇博文（如果你的应用或产品有博客）或推文。

根据组织的性质，可以采取更多措施。 重要的是不要忘记传达您的产品有新版本可用。

8. 梳理问题跟踪器

执行发布后，您可能需要更新某些工单的状态，以跟踪当前生产中的错误修复或功能。 通常，这涉及更改一些标签（对于小型项目，我使用发布待定标签，在发布完成后我将其删除）。

如果您为每个新版本使用里程碑，您可能需要更新其状态或将其标记为已完成。 一些问题跟踪器甚至可以让您计划发布并将其与 sprint 保持一致，跟踪错误是否阻碍了发布以及其他有用的信息。

这完全取决于您如何使用该工具。 我只想指出，更新问题跟踪器中的信息的任务应该包含在您的发布清单中。

关于自动化发布过程

读者可能已经注意到，除了上面概述的更改日志步骤之外，上述许多步骤也可以自动化。

自动化发布过程的某些部分的能力是一个巨大的胜利，并节省了大量时间。 我建议创建脚本，或者弄清楚如何自动化各个步骤，然后朝着持续交付目标努力。 持续交付可以降低风险、降低成本并减少开发人员在管理发布方面需要花费的时间。 因此，就分配给开发的时间而言，您将能够更频繁地发布并提高生产力。

DevOps 公司的圣杯是能够通过按下一个按钮（或运行一个命令）来启动一个新版本，这将自动触发发布过程，或者更好的是，一个系统会在一个时间发布你的软件的新版本。指定时间。 当然，这很难实现，因为您还需要自动化很多测试过程，但这并非不可能。

采用最佳实践

在本节中，我将描述一些我认为方便的推荐实践，以使发布过程更顺畅，或者在出现问题时采取安全措施。

寻找最适合发布的日子

我通常在星期四中午和下班之间发布我正在开发的应用程序。

如果您周一至周五工作，那么在周五启动并不是一个好主意。 如果发布后出现问题，您将在周一之前没有时间修复它（除非您想在周末工作）。 这就是为什么在星期四发布更方便，因为您有星期五在部署后监控新版本、修复任何问题或进行回滚。

如果您正在管理 Web 应用程序，另一件重要的事情是要知道您的大多数用户所在的时区。 您应该在流量较低的时段安排发布时间，以尽量减少出现故障时的潜在损害。 有时，当您的用户群遍布全世界时，这可能会很棘手，但无论如何，您应该做一些研究并确定最佳时间。

在新版本发布之前备份您的数据库

如果您没有计划定期备份数据库，我强烈建议您在发布过程中添加一个步骤，以便在开始发布之前执行备份。

分阶段推出

有没有想过，为什么当出版商宣布他们推出了一项新功能时，您的手机需要几天甚至几周的时间才能使用该功能？ 这是因为许多公司使用分阶段推出。

Facebook 已经这样做了很长时间。 它在 5% 或 10% 的用户上测试一项新功能，然后逐渐增加，直到达到 100% 的用户群。 在分阶段推出阶段，您需要仔细查看用户反馈和崩溃报告。 有了这些信息，您就可以在错误影响到每个用户之前推迟发布或修复错误。

Android 的开发者控制台上有一个很好的工具，可以为您的 Android 应用实现分阶段部署。

持续集成

持续集成是一种值得拥抱的实践，原因有很多。 首先，它可以让您及早发现错误，从而提高成功发布的比率。 其次，这是在实施如前所述的持续交付和完全自动化之前的第一个合乎逻辑的步骤。

Martin Fowler 是持续集成的大力倡导者。 他描述了在使用这种做法时可以为您的发布过程添加的大量好处。 这是一个很大的话题，有很多关于它的书籍和博客文章，我在这里提到它是因为我相信它会让您对您的运营更有信心。 在使用 CI 的众多优势中，您会发现：降低风险、提高可见性以了解哪些工作正常、哪些不工作、更早地检测错误、提高部署频率等等。

实施 CI 的出发点是建立一个“持续集成服务器”； 可以尝试的一些不错的工具是：CruiseControl、Bamboo、Jenkins 和 Travis。

尾声：一切都会好起来的

积极地，我们都捍卫我们所扮演的角色遗憾的是，时代已经到了，我们已经看到了这一切，信任的篝火，阵阵的痛苦这并不重要，你不用担心，它会一切都解决了

出口曲，杀手

最后，我想说的是，为您的应用程序制定明确的发布流程非常重要，无论其复杂性、用户群或您的组织有多小。

如果您不这样做，我建议您开始考虑一些基本步骤，使用本指南和其他类似指南，并与您的团队一起集思广益以提出初稿。 在您的下一个版本中尝试一下，然后进行迭代。 最终，您将构建自己的发布流程。

之后，开始考虑如何自动化部分流程。 想想可以改进的地方。 探索通过合并小的优化来减少发布时间的方法。 自动化应该是您的最终目标； 但是，不要从一开始就计划，否则你会因为尝试如此大的飞跃而失败。 与每个过程一样，最好逐渐改进它。

您是否有任何其他技巧或指南用于启动应用程序的新版本？ 如果是这样，请告诉我。 我不是来自 DevOps 世界，我只是一个开发人员，恰好组织和结构化，但与许多老手相比，我在这方面仍然是新手，所以如果你有任何评论或联系我要补充的东西。