通往持续交付的现实世界之旅 - 第 2 部分

如果你还没看过，请阅读 第 1 部分

从手动部署到自动化部署，只需 367 个简单步骤

在经过数月的艰苦奋斗，终于推出了我们当时羽翼未丰的拍卖管理软件包的第一个版本，尽管存在种种不足。 它由一个运行在复制的 SQL 数据库和多个站点上的 WPF 桌面应用程序组成。 之后不久，我们推出了后端操作核心 Web 应用程序的 1.0 版本。 紧接着又推出了一个新的公共网站、内部 Web 服务和公共集成 API 服务。 当然，每一个部分都是手动部署的。 我知道我们必须开始自动化，并且有传言说要建立一个 CI 服务器，但是谁有时间做这些事情呢？ 毕竟，业务需要所有紧急的功能，而且同时还需要解决所有生产问题。（捂脸）

时间流逝，系统成长，团队壮大，应用程序和端点数量增加，部署时间变长，场景变得更加复杂，问题出现得更快、更大，业务越来越沮丧，开发人员越来越疲惫，整个事情变得越来越脆弱，而且也没那么有趣了。

部署时间达到 2 到 4 个小时。 而且由于系统在部署期间处于不一致状态，我们无法在工作时间内部署。 所以我们开始在周五晚上 9 点进行部署。 哇，你可能会说，每周一次的生产部署… 但这正在扼杀我们。 我们是一群热爱编程的极客。 喜欢基础设施、服务器配置和部署… 并不喜欢。 这对我们的家人和个人生活来说也不健康。

我们试图从业务部门获得支持，以便投入时间。 但是，当业务面临将新的 Stupendifyer 投入生产，或者让开发团队花一些时间处理他们神秘的流程和问题时… 我们可以说，无论意图多么好，他们总是选择蓝药丸。

插曲：我的妻子，在看到这篇博文的标题后，并从母亲的角度（她生了我们 3 个了不起的孩子），提到持续交付很可能听起来像是她能想象到的最糟糕的事情之一。

慢慢地，我开始意识到，最有能力让开发团队生活更好的人是开发团队。 业务部门不生活在我们的世界。 他们感觉不到我们的痛苦。 他们不理解我们的问题。 因此，他们可能永远不会优先考虑我们需要的“功能”。 并不是因为他们很糟糕，或者怀有恶意。 仅仅是因为他们生活在一个完全不同的范式中。

所以我们停止征求许可，只是开始进行我们需要的更改，以改进交付管道，并穿插在我们的“正常”开发中。 这绝非易事，因为压力没有缓解，但团队在一些领军人物的带领下，一次又一次地解决问题。 因此，我们缓慢、系统、持续地开始占据上风。 系统一个接一个地被配置为通过 CI 服务器运行，然后自动部署。 我们编写了一个工具来将我们的数据库脚本应用于数据库（DbScriptomate），然后将其自动化。 我们仍然在周五晚上 9 点部署，但部署时间开始缩短到 2 小时以内。 然后缩短到 1 小时以内。 然后到 30 分钟。

我们达到了 100% 自动化部署的辉煌之地。

我们实现了自动化，但事情还不太乐观。 经常由于我们部署的更改导致问题（是的，尽管我们有一大批自动化测试），然后我们会在周末花费数小时来排除故障和解决问题。 是时候进入下一个阶段了。

在第 3 部分中，我们将从 自动化到持续

CodeProject