正式发布管理过程(如果有的话)

在一些团队配置中, 尤其是在初创企业中, 没有DevOps, 也不是基础设施工程师, 在发布产品的新版本时提供支持.

此外, 不像大型官僚公司有明确的正式流程, the CTO or Head of Software 开发ment team in a startup is often not aware of the complexities of the software 释放 management process; a few 开发ers 在 company may be aware of the complex details of the process, 但不是所有人. 如果这个知识不是 记录彻底，我相信这会导致混乱.

在本文中, 我将尝试提供一些关于如何正式发布过程的提示, 尤其是从开发者的角度来看.

进入软件发布检查表

您可能熟悉某些操作的检查表的概念，如 检查表的宣言，阿图尔·加万德的一本书. 我相信正式的发布过程(就像软件开发世界中的许多其他任务一样)为开发人员提供了实现该协议的机会. A 发布过程检查表 应该保存在共享文档中吗, 最好是以协作wiki的形式, 或者谷歌硬盘上的电子表格.

通过和团队分享这份重要的文件, 并授予编辑权限, 每个成员都可以访问正式定义的发布过程. 这使他们能够理解流程是如何工作的. 此外, 与其他团队成员进行讨论, 它使团队能够不时地改进它. 这将带来透明度，并允许整个团队实时访问发布期间发生的事情, 完成了多少步骤啊, 是谁干的.

看看这个电子表格, 利益相关者可以决定“去”还是“不去”,，基于步骤的结果. 例如, 如果压力测试在测试环境中出错, 基于事件，项目经理可能决定取消产品发布.

建议步骤使用作为基础

在本节中, 我将提出一些步骤，您可以使用这些步骤为您的发布过程构建您自己的清单. 其中一些步骤 都不是强制性的吗. 每个应用程序都是不同的，每个组织都以不同的方式运作, 所以，你可以自由地去适应并做出改变，以更好地适应你的工作流程.

1. 创建一个发布分支

你可能熟悉的概念是 Git工作流，或者发布分支的概念，这是一个已经被解释过的主题 在之前的一篇博文中.

理想情况下，你应该至少有三个分支:

• 主:这应该反映生产环境的当前状态. 每一次新的承诺 主 应该只包含一个新版本吗.
• 开发:这个分支应该包含完成的(和测试过的)即将到来的特性. 通常为每个特性创建一个单独的分支，然后将其合并到 开发 当特性准备好时.
• 释放: 释放 分支是准备发送到生产环境的提交的集合, 加上一些与该版本相关的附加小错误修复.

注意到 释放 一旦发布完成，应该删除分支, 因此，这些分支一直在创建和销毁, 不像 主 or 开发，它们总是一样的.

为了创造一个新的 释放 分支，来自 开发 在你的git终端中，输入:

$ git checkout -b 释放/x.y.z

使用一种命名约定(如上面定义的)来替换x是很方便的.y.大调Z.小.根据你的需要打补丁版本号(这是一个你应该在你的团队中定义并坚持的策略).

这很重要, 也, 如果你在发布分支中修改了一些bug, 您不应该忘记将它们合并回 开发. 发布分支的主要目的是预览应用程序在投入生产后的表现.

2. 凹凸版

的版本号，下一步是增加(修改或增加) 释放 分支.

你应该打开AndroidManifest.XML / package.Json / pom.或任何应用程序的版本存储在您的项目(YMMV), 更新版本号, 然后将更改提交到当前 释放 分支.

更新版本号很重要，原因有两个.

第一个, 您可以跟踪和映射每个版本中引入的特性, 和第二, 如果他们需要做一些故障排除或与您联系以获得支持，您将了解他们正在使用的版本. 如果你正在开发一款手机应用, 在此步骤中要更新的版本号通常显示在用户端, 在 关于 Section或in 谷歌玩 or 苹果应用商店.这一步也是更新依赖于环境的配置文件的好机会(尽管我建议将它们保存在单独的存储库中)。, 例如使分支指向生产数据库, 或者在构建过程中需要的任何其他调整.

最后，建议大家推一下 释放 分支到原点，以便其他开发人员可以使用:

$ git push -u origin 释放/x.y.z

3a. 合并发布分支到主控并标记它

只有 主 分支应该部署到生产环境中，因此在这一步中，我们需要合并 释放 分支成 主.

$ git checkout 主
$ git merge——no- off 释放/x.y.z
$ git push

的 ——no-ff 标志是可选的, 然而, 建议使用它来强制创建一个新的提交对象, 尽管合并可以使用快进技术来完成.

接下来，是时候标记发布了 主 分支机构:

$ git tag - 1.y.Z -m“新版本的描述，包含的特性或修复”

标记很有用，因为您要在git存储库中持久化历史中的特定点, 稍后，您可以从特定标记中重新创建一个单独的分支.

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

另一种常用的替代方法是使用a 把请求 合并 释放 分支成 主.

这种方法有许多优点. 为合作创造了一个新的空间, 团队可以使用哪个来讨论各种与发布相关的问题. 此时是添加一个额外的门以合并代码审查过程的好时机, 同时有更多的眼球监视将要引入的代码, 并讨论可能的修改.

一些允许您在工作流中实现拉取请求的工具是 GitHub, Bitbucket都 和 GitLab (合并请求，因为他们在后者上调用它). 有了这些工具, 不需要手动输入git命令, 而不是, 您使用web界面来设置源分支(释放)及目的分行(主), 然后添加一个或多个审阅者, 所有人都可以对这些新变化写内联评论, 提出改进建议, 等等.......

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

4. 将主服务器部署到生产环境

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

此时，您已经准备好部署更改并使其生效. 继续进行部署 主 分支. 这一步将取决于您正在使用的基础架构堆栈. 它可能涉及到连接到Amazon EC2实例来上传应用程序, 或者推到Heroku遥控器上, 或者通过ssh连接到VPS复制新版本, 或者其他过程.

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

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

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

$ git checkout 开发
$ git merge 释放/x.y.z

现在是时候把 释放 分支机构:

$ git 分支 -d 释放/x.y.z

6. 更新日志生成

在项目的根目录下应该有一个名为CHANGELOG的文件.Md(或同等的)，每当有新版本时，您应该添加一个新条目，以便记录其中包含的所有内容, 比如bug修复, 新功能, 已知的问题, 以及以发行说明形式提供的任何其他相关信息. 这是 对用户和贡献者非常有用 查看项目的每个发行版(或版本)之间所做的更改.

变更日志条目包括日期、版本号和一些关于发布的注释. 分录应按时间倒序排列. 这里有一个我一直在使用的简单模板，你可以适应你的项目:

  |  
<开发er's name in charge of 释放> | <开发er's email>
特点: 
* :  ()
* ...
缺陷修正: 
* :  ()
* ...
增强功能: 
* :  ()
* ...
可选:已知问题加上其他发行说明.

除了, 通过编写一个遍历git日志并自动生成changelog条目的基本脚本，可以完全自动化此步骤, 或者通过使用同样的工具, 如:

• Github Changelog Generator，由skywinder，
• ReadmeGen 由fojuth
• github-changeslalitkapoor著

但是要记住, 您获得的自动化程度与提交消息格式的严格程度成正比. 我相信与团队就提交消息的特定格式达成一致始终是一种很好的实践. 通过遵循有关提交消息样式的指导方针, 它们将更容易解析，因此更有可能使变更日志的生成自动化.

7. 与利益相关者沟通

在这里，你通常会做以下一些事情:

• 通过内部消息传递工具(如.g.(Slack)一个新版本已经完成. 我建议创建一个新的通道(I.e.: #版本)的唯一目的是沟通发布相关事件. 很容易在Slack频道中添加钩子，以便在采取行动后发布消息.
• 另外, 向涉众发送一封带有变更日志链接的电子邮件, 或者附带的变更日志文件.
• 写一篇博文(如果你有应用或产品的博客)或tweet.

根据组织的性质，可以采取更多的行动. 重要的是不要忘记传达你的产品有新版本可用.

8. 梳理问题跟踪器

执行释放后, 您可能需要更新一些票据的状态，以跟踪错误修复, 或特性, 目前正在生产中. 通常，这涉及到更改一些标签(对于小项目，我使用 释放-pending 标签，我在发布完成后将其删除).

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

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

关于自动化发布过程

读者可能已经注意到了这一点, 除了上面概述的更改日志步骤之外, 前面提到的许多步骤都可以自动化, 太.

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

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

拥抱最佳实践

在本节中，我将描述一些我认为很方便的推荐实践, 要么是为了让释放过程更顺利，要么是为了在出现问题时采取安全措施.

找一个最合适的日子进行释放

我通常在周四中午到下班时间发布我正在开发的应用程序.

如果你从周一工作到周五，那么在周五发布产品就不是个好主意. 如果释放后出现故障, 你要到周一才有时间修复它(除非你想在周末工作)。. 这就是为什么在周四发布更方便, 因为在部署新版本后，您有周五的时间来监视它, 修复任何问题, 或者回滚.

如果你正在管理一个web应用，还有一件重要的事情需要提及, 要知道大多数用户所在的时区吗. 您应该在流量较低的时间段发布，以便在出现故障时将潜在的损害降至最低. 有时, 当你的用户群遍布全球时，这可能会很棘手, 但无论如何, 你应该做些调查，然后决定最好的时间.

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

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

上演了糊涂事

想知道为什么吗?, 当发行商宣布他们推出了一项新功能, 需要几天的时间, 甚至是几周, 让你的手机也有这个功能? 这是因为许多公司采用分阶段推出的方式.

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

Android的开发者控制台有一个很好的工具，可以为你的Android应用实现分阶段的发布.

持续集成

持续集成是一种值得接受的实践 有很多原因. 首先，它允许您尽早发现错误，增加成功发布的几率. 其次, 这是实现之前描述的持续交付和完全自动化之前的第一个逻辑步骤.

马丁·福勒是 持续集成. 他描述了在使用这种实践时可以添加到您的发布过程中的大量好处. 这是一个很大的话题，有很多关于它的书籍和博客文章, 我在这里提到它，是因为我相信它会给你们的业务带来更大的信心. 在使用CI的众多优点中, 你会发现:风险降低了, 增加可见性，以了解哪些工作有效，哪些工作无效, 更早地发现bug, 增加部署频率, 还有更多.

实现CI的起点是设置一个“持续集成服务器”;可以尝试的一些不错的工具有:CruiseControl, 竹子, 詹金斯和特拉维斯.

插曲:一切都会解决的

我们都积极地捍卫我们所扮演的角色 遗憾的是，时代来送你上路 我们都见过了，信任的篝火，痛苦的洪水 没关系，别担心，一切都会解决的

插曲，杀手

总结一下, 我想说的是，为你的应用制定一个明确的发布流程非常重要, 不管它有多复杂, 用户群, 或者你的组织有多小.

如果你不知道, 我建议你开始考虑一些基本步骤, 使用这个指南和其他类似的指南, 和你的团队一起进行头脑风暴，想出一个初稿. 在你的下一个版本中尝试一下，然后迭代. 最终，您将构建自己的发布流程.

在那之后，开始思考如何 自动化部分流程. 想想可以改进的地方. 探索通过结合小优化来减少发布时间的方法. Automation should be your ultimate 目标; 然而, 不要一开始就计划好, 否则你会因为尝试这么大的飞跃而失败. 与每一个过程一样，最好是逐步改进.

在发布新版本的应用程序时，你还有其他的技巧或指导方针吗? 如果有，请告诉我. 我不是来自 DevOps 世界, 我只是一个很有条理的开发者, 但与许多老兵相比, 在这方面我还是个新手, 所以，如果你有什么要补充的，请随时评论或联系我.