srcmini本文概述
正式发布管理流程(如果有)
在某些团队配置中, 尤其是在初创公司中发现的那些配置中, 当发布新版本的产品时, 没有DevOps或基础架构工程师来提供支持。
此外, 与具有定义好的正式流程的大型官僚公司不同, 初创公司的CTO或软件开发团队负责人通常并不了解软件发布管理流程的复杂性。公司中的一些开发人员可能知道该过程的复杂细节, 但不是所有人。如果这些知识没有得到充分记录, 我相信这可能会引起混乱。
在本文中, 我将尝试提供一些有关如何规范发布过程的技巧, 尤其是从开发人员的角度。
输入软件发行清单
根据Atul Gawande的《清单宣言》, 你可能对某些操作的清单很熟悉。我相信正式的发布过程(就像软件开发领域中的许多其他任务一样)为开发人员提供了实施此协议的机会。发布过程清单应保存在共享文档中, 最好以协作Wiki的形式保存, 或保存在Google云端硬盘上的电子表格中。
通过与团队共享此重要文档, 并授予编辑权限, 每个成员都可以访问正式定义的发布过程。这使他们能够了解该过程的工作方式。而且, 在与其他团队成员进行讨论之后, 它使团队能够不时地对其进行改进。这样可以提高透明度, 并允许整个团队实时访问发布过程中发生的事情, 完成的步骤以及由谁进行操作。
通过查看此电子表格, 利益相关者可以根据这些步骤的结果来决定”执行”与”不执行”。例如, 如果压力测试在测试环境中出错, 则基于事件, 项目经理可能会决定取消生产版本。
一个简单, 经过深思熟虑的电子表格清单可以对你的软件版本管理流程产生很大的影响。
鸣叫
建议用作基础的步骤
在本部分中, 我将建议一些步骤, 你可以使用这些步骤为发布过程建立自己的清单。其中某些步骤绝不是强制性的。每个应用程序都不同, 每个组织的工作方式也不同, 因此可以随时进行调整并进行更适合你工作流程的更改。
1.创建一个发布分支
你可能熟悉Git Workflow的概念或发行分支的概念, 在上一篇博客文章中已经解释了这个主题。
理想情况下, 你至少应具有三个分支：
- 大师：这应该反映生产环境中的当前状态。 master上的每个新提交都应仅包含一个新发行版。
- 开发：此分支应包含已完成(并经过测试)的即将发布的功能。通常为每个功能创建一个单独的分支, 然后在功能就绪时将其合并以进行开发。
- 发布：发布分支是准备提交到生产环境的提交集合, 以及与发布相关的一些其他小错误修复。
请注意, 发布完成后应立即删除发布分支, 因此, 与master或development总是一样的, 这些分支始终被创建和销毁。
为了创建一个新的发布分支, 在git终端的develop分支中输入：
$ git checkout -b release / x.y.z
使用命名约定(例如上面定义的约定)很方便, 可以根据需要用major.minor.patch版本号替换x.y.z(这是你应该在团队中定义并遵循的策略)。
同样重要的是, 如果你将一些错误修复程序编码到发行分支中, 则不要忘记将其合并回开发。 release分支的主要目的是获得有关应用程序投入生产后的行为的预览快照。
组织和跟踪不同的发行分支是发行管理的关键方面。
鸣叫
2.凹凸版本
下一步将是更改(修改或增加)发行分支上的版本号。
你应该打开AndroidManifest.xml / package.json / pom.xml /或将应用程序版本存储在项目(YMMV)中的任何位置, 更新版本号, 然后将更改提交到当前发行版分支。
由于两个原因, 更新版本号很重要。
首先, 你可以跟踪和映射每个版本中引入的功能, 其次, 如果他们需要进行一些故障排除或与你联系以获得支持, 你将知道他们正在使用的版本。如果要构建移动应用程序, 则通常在用户端, “关于”部分或Google Play或Apple App Store中显示此步骤中要更新的版本号。此步骤也是更新与环境相关的好机会-配置文件(尽管我建议将它们保存在单独的存储库中), 例如将分支指向生产数据库, 或进行构建过程中需要的任何其他调整。
最后, 建议你将发布分支推到原始位置, 以便其他开发人员可以使用它：
$ git push -u原始版本/x.y.z
3a。合并发布分支以对其进行主控和标记
仅应将master分支部署用于生产, 因此在这一步中, 我们需要将release分支合并到master中。
$ git checkout master
$ git merge --no-ff release/x.y.z
$ git push
–no-ff标志是可选的, 但是, 即使可以使用快进技术完成合并, 也建议使用该标志以强制创建新的提交对象。
接下来, 是时候在master分支上标记发布了：
$ git tag -a x.y.z -m’包括新版本, 功能或修复的说明’
标签非常有用, 因为你将这个特定点保留在git存储库中的历史记录中, 以后你可以回来根据特定标签重新创建一个单独的分支。
3b。使用拉取请求合并发布分支
经常使用的另一种选择是使用拉取请求将发布分支合并到master。
这种方法有很多优点。创建了一个用于协作的新空间, 团队可以用来讨论与发行相关的各种问题。这是添加一个额外的门来合并代码审查过程的好时机, 同时有更多的注意力来监视将要引入的代码并讨论潜在的修改。
GitHub, Bitbucket和GitLab(合并请求, 在后者上称为合并请求)可让你将拉入请求实现到工作流中的一些工具。使用这些工具, 你无需手动键入git命令, 而是使用Web界面设置源分支(发行版)和目标分支(主版), 然后添加一个或多个审阅者, 所有审阅者都将能够对这些新更改发表内联评论, 提出改进建议等。
在所有审阅者批准请求请求之后, 你可以通过按下UI上的按钮将更改自动合并到主文件中。
4.将主服务器部署到生产环境
在此阶段, 最好的做法是在团队中部署一个测试人员进行烟熏测试(可以在单独的清单中进行定义)。一个很好的建议是将master分支部署到一个单独的测试环境中。然后, 测试人员可以执行一些基本操作, 以确保在最新版本的合并后没有出现任何问题。如何进行烟雾测试不在本文的讨论范围之内, 但是你可以在网络上找到很多有关它的资料。冒烟测试的结果可以集成到发布清单/电子表格中, 记录任何出错的地方。
此时, 你就可以部署更改并使它们生效。继续并部署master分支。此步骤将取决于你使用的基础结构堆栈。它可能涉及连接到你的Amazon EC2实例以上传你的应用程序, 或推送到Heroku远程服务器, 或通过ssh连接到你的VPS以复制新版本, 或执行其他任何过程。
进行冒烟测试, 将master分支部署到单独的测试环境中, 确保部署成功。
鸣叫
上载应用程序后, 请确保已成功部署该应用程序, 并且该应用程序可以按预期运行。
5.合并回到开发和删除发行分支
现在, 该发行版已接近完成, 你将需要将发行版分支合并到development中, 以更新后者上的版本号, 并将所做的所有错误修复都转移到主开发分支上：
$ git checkout develop
$ git merge release/x.y.z
现在是时候删除发布分支了：
$ git branch -d版本/x.y.z
6.变更日志生成
在项目的根目录中应有一个名为CHANGELOG.md(或同等名称)的文件, 在此文件中, 应有一个新条目, 以便在发行新版本时对其进行记录, 以记录其中包含的所有内容, 例如错误修复, 新功能, 已知问题, 以及发布说明形式的任何其他相关信息。这对于用户和贡献者查看项目的每个发行版(或版本)之间所做的更改非常有用。
更改日志条目包括日期, 版本号和有关发行版的一些注释。条目应按时间倒序排列。这是我一直在使用的一个简单模板, 可用于你的项目：
<app's name or component released> <version x.y.z> | <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日志并自动生成变更日志条目的基本脚本, 或使用执行此操作的工具, 可以完全自动化此步骤, 例如：
- Github Changelog Generator, 由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领域的人, 我只是一个组织整齐, 结构合理的开发人员, 但是与许多资深人士相比, 我仍然是这方面的新手, 请随时发表评论或与我联系要添加的东西。
评论前必须登录！
注册