2019 年，Shopify 在博客中分享了自己成功合并千名开发人员工作的经验，并介绍了工具 Merge Queue v2，很多人都好奇为什么 Shopify 要构建这样的一款工具呢？
其实答案很简单，不少企业发展到一定阶段后就会遇到这样的情况。随着业务发展，Shopify 意识到市面上没有任何现成的产品可以彻底解决他们面临的困难。从更长远地来看，Shopfiy 认为公司应该为开发人员提供尽量完善的开发体验，并要塑造一种 " 软件发布文化 "，所以就开始不断改进现有的工具链和流程方法。
Shopify 是这样定义企业文化的：
Shopify 所有人信念和行为的总和。
软件发布工作是开发工作的子集，自然，" 软件发布文化 " 也要和企业文化保持一致。Shopfiy 的软件发布工作规范与其他企业没有太大不同，比如他们要求错误的更改不应该流入生产环境，破坏用户体验；生产环境中所做的更改不应该牺牲安全性等等。
通往罗马的道路不止一条，同样的软件发布文化，也有很多可选的实现路径。Shopify 认为，企业支持团队应该为开发人员开辟一条路径，让他们自由发挥生产力和创造力，并实现自己的目标。企业应该营造一种氛围，让版本发布成为一种胜利时刻。
Shopify 如何评估软件发布文化
如何塑造软件发布文化？首先要考虑以下问题：
-
开发人员希望选择怎样的工作方式？
-
对他们来说哪些事情比较重要？
-
他们如何看待用来支持他们的工具？
-
他们想知道多少幕后信息，想了解多少自己使用的工具背后的知识？
这些问题往往没有单一的答案，尤其是 Shopify 这家企业中每天参与软件部署工作的人员众多，涉及的岗位也多种多样。Shopify 选择了一些主动和被动的方法来评估企业内部的软件发布文化，这些方法不分先后，它们共同描绘出了一幅关于开发人员如何使用各种工具的图景。
其中，被动方法主要用来管理和汇总输入的信息，并不需要企业支持团队去做很多工作。其中，有一个方法是 开发人员满意度调查，这是对 Shopify 全公司的开发人员每半年进行一次的调查研究。开发人员需要报告很多信息，比如说他们对自己所使用的工具的满意度，或者工作中哪些环节非常浪费时间等等。
此外，公司还专门设立了面向所有人开放的 Slack 频道。在这个频道上，产品用户可以从开发团队或其他用户那里获得支持，并报告他们遇到的问题。Shopify 团队会积极参与这些频道的互动，培养社区氛围并鼓励开发人员分享经验。需要注意的是，这些频道并不是用来获取产品反馈的主要渠道。
总的来说，他们希望能主动找出产品和服务中的痛点所在，而且意识到了这个过程并不能过分依赖用户，因此 Shopify 也采取了一些积极的措施来找出最重要、优先级最高的问题。
一种措施叫做 dogfooding。公司内开发团队用来发布代码的工具是和构建与维护代码的工具完全一致的。这样就很容易找出服务的缺陷所在，并在出现产品问题时站在用户的视角上理解其影响。
另一项重要资源是 Shopify 的 内部支持团队。他们需要帮助用户，还要支持企业内部不断发展的工具套件，这是很艰巨的挑战。他们需要诊断问题，帮助用户找到合适的团队来指导他们解决这些问题。他们能够找出用户在当前工作流程中遇到的常见痛点以及概念和原型的潜在问题。
最后，在添加新功能或更改现有工作流程时，Shopify 会在整个过程中实施 用户体验研究分析：
- 更好地了解用户行为和期望
- 在开发概念和原型时测试它们
当开发人员发布 PR 时，团队会单独考察开发人员的想法，了解他们都在考虑哪些内容，在制定决策时都有怎样的根据。团队会与设计师和撰稿人等用户交流，学习他们的日常工作流程，了解他们所依赖的工具和用法。公司会让实习生和新人测试产品原型，从中了解外部和新鲜视角的观点，并挑战原有的产品假设。
有了这些流程，企业就能在整个构建和发布过程中都能从真实用户那里获得一手反馈，进而打造更好的产品和服务。
反馈是一种礼物 在 Shopify 经常提到的一句话就是，反馈是一种礼物。
评估软件发布文化的目的是创建一个反馈循环，让用户可以轻松谈论他们遇到了哪些障碍，收到反馈的开发团队会重视这些意见并尝试采取对策。
还有很重要的一点是，用户的反馈会让产品团队充满动力，即便反馈是负面的，这也是用户重视产品、希望产品变得更好的一种证明，这自然会鼓励团队，甚至让他们在面对困境时振作起来。用户希望自己的反馈能有价值，这是企业要给用户营造的氛围，企业的软件开发文化和工具链应该支持这种良性循环，让所有人都能从中获益。
Shopify 的软件发布流程
Shopify 的软件发布流程是怎样的形态，又有哪些可以改进的部分呢？
发布管道
这就是 Shopify 发布管道的路径。一开始是拉取请求（PR），然后是持续集成（CI）/ 合并，接着是金丝雀部署，最后是生产发布。
这套流程的第一步是开发人员创建 PR，然后在准备交付时发出一条 /shipit 命令。接下来，Merge Queue 系统会尝试将 PR 与主干 Master 集成起来。
当 Merge Queue 确定更改可以成功集成时，PR 就会合并到 Master，并部署到 Shopify 的金丝雀基础架构中。金丝雀环境会随机接收所有传入请求的 5％。
开发人员有一套工具，可以在金丝雀环境中测试更改 10 分钟的时间。如果没有手动干预，并且金丝雀自动分析不会触发任何警报，则更改将部署到生产环境中。
发布与恢复机制
每一位开发人员都希望能被信任，并对自己的工作拥有自主权。开发人员应该能控制自己 PR 的整个发布过程。
在 Shopify 的软件发布流程中，开发人员能控制整个发布过程。这里不存在什么发布管理器、注销或者审核窗口。
然而是人就会犯错，出现问题是难免的，Shopify 当然也不例外。为此，公司建立了一套基础架构来限制不良更改的爆炸半径。最重要的是，企业相信每位开发人员都应该承担自己应负的责任，并且如果他们的更改捅了篓子，他们也应该能自己去恢复它。
一旦准备好了修复程序（修复 - 转发或还原），开发人员就可以使用一条 /shipit --emergency 命令快速追踪整个修复进程。Shopify 没有那么多恢复协议，而只有一个 紧急状况 功能，这样就能让开发人员以最快的速度完成恢复操作。
快速发布
开发人员希望快速发布。
发布速度是大多数企业应用程序的一个关键要素。对于开发人员而言，如果能一天多次发布代码并立即将其发送给最终用户，就能极大提高生产力。但更重要的是，采用快速的发布流程可以带来同样快速的恢复流程。
为了真正加快发布过程，企业是需要投入资源和成本的。除了专门的基础架构团队，Shopify 还管理着自己的 CI 群集，容量高达数千个节点。
自动化
开发人员不想执行重复性的任务。计算机最擅长做重复工作，所以这类工作应该尽可能地自动化。Shopify 在诸如连续部署和金丝雀分析之类的地方实现了自动化。
在 Shopify，开发人员用不着按一个部署按钮，自动化流程会持续部署到金丝雀和生产环境。
自动化固然很棒，但是某些时候开发人员还是需要手动控制的。在紧急情况下，开发人员可以锁定自动部署并转为手动部署。
原文链接：
https://engineering.shopify.com/blogs/engineering/software-release-culture-shopify
评论