揭秘 Shopify 的软件发布流程，如何做到合并上千程序员的工作？( 二 ) _程序员

有了这些流程，企业就能在整个构建和发布过程中都能从真实用户那里获得一手反馈，进而打造更好的产品和服务。
反馈是一种礼物在 Shopify 经常提到的一句话就是，反馈是一种礼物。
评估软件发布文化的目的是创建一个反馈循环，让用户可以轻松谈论他们遇到了哪些障碍，收到反馈的开发团队会重视这些意见并尝试采取对策。
还有很重要的一点是，用户的反馈会让产品团队充满动力，即便反馈是负面的，这也是用户重视产品、希望产品变得更好的一种证明，这自然会鼓励团队，甚至让他们在面对困境时振作起来。用户希望自己的反馈能有价值，这是企业要给用户营造的氛围，企业的软件开发文化和工具链应该支持这种良性循环，让所有人都能从中获益。
Shopify 的软件发布流程Shopify 的软件发布流程是怎样的形态，又有哪些可以改进的部分呢？
发布管道

文章插图

发布管道路径
这就是 Shopify 发布管道的路径。一开始是拉取请求（PR），然后是持续集成（CI）/ 合并，接着是金丝雀部署，最后是生产发布。

文章插图

PR 和 /shipit 命令
这套流程的第一步是开发人员创建 PR ，然后在准备交付时发出一条 /shipit 命令。接下来， Merge Queue 系统会尝试将 PR 与主干 Master 集成起来。

文章插图

PR 合并到 Master ，金丝雀部署
【揭秘 Shopify 的软件发布流程，如何做到合并上千程序员的工作？】当 Merge Queue 确定更改可以成功集成时， PR 就会合并到 Master ，并部署到 Shopify 的金丝雀基础架构中。金丝雀环境会随机接收所有传入请求的 5％。

文章插图

更改部署到生产环境
开发人员有一套工具，可以在金丝雀环境中测试更改 10 分钟的时间。如果没有手动干预，并且金丝雀自动分析不会触发任何警报，则更改将部署到生产环境中。
发布与恢复机制每一位开发人员都希望能被信任，并对自己的工作拥有自主权。开发人员应该能控制自己 PR 的整个发布过程。

文章插图

开发人员控制整个过程
在 Shopify 的软件发布流程中，开发人员能控制整个发布过程。这里不存在什么发布管理器、注销或者审核窗口。

文章插图

限制不良更改爆炸半径的基础设施
然而是人就会犯错，出现问题是难免的， Shopify 当然也不例外。为此，公司建立了一套基础架构来限制不良更改的爆炸半径。最重要的是，企业相信每位开发人员都应该承担自己应负的责任，并且如果他们的更改捅了篓子，他们也应该能自己去恢复它。

文章插图

开发人员可以使用 /shipit--emergency 命令快速跟踪修订
一旦准备好了修复程序（修复 - 转发或还原），开发人员就可以使用一条 /shipit --emergency 命令快速追踪整个修复进程。Shopify 没有那么多恢复协议，而只有一个紧急状况功能，这样就能让开发人员以最快的速度完成恢复操作。
快速发布开发人员希望快速发布。