似乎已经过了很久，但就在几年前，我还在为一个大型系统集成商领导一个价值 1 亿美元的政府项目，该项目涉及 50 多名开发人员、20 多名测试人员、15 多名经理、5 多名运维人员以及其他角色。每周我们都要进行部署。

尽管使用了 Scrum、Cruise Control、SVN、Java、Eclipse、Guava、Google Guice、UML、JUnit、PMD、Findbugs、Checkstyle、MDD、TDD、eclEmma 和大多数现代工具；我们的部署过程仍然是一个脆弱、漫长、手动、需要大量人员参与的过程。每个周五晚上我们开始。一封长长的电子邮件线程开始了该过程，其中包含一个文本检查列表，我们在该过程中每个人完成他们的部分时来回发送电子邮件。另一位架构师或我将管理该过程并负责 Go/No Go 决策和关键的 DB 比较步骤。我们使用一家大型软件公司的专有垂直框架作为项目的基础。它涉及手动运行 SQL 脚本、运行 diff 脚本、目视比较某些项目、检查版本控制检查列表、检查 Cruise Control 结果、JUnit / 代码覆盖率 HTML 和一些其他生成的报告。UNIX 管理员将复制巨大的 EAR 文件、SQL 和大量巨大的 XML 文件。到达那里后，他们将运行一些 shell 脚本来更改一些内容，有时使用环境变量。然后将它们移动到特殊目录，Java 应用程序服务器将停止，一切都会备份。EAR 将被移动，数据源和其他配置将被复制和检查。DB 更改脚本将针对 Oracle 运行，并且元数据将通过众多 sql 脚本进行更新/插入/删除。服务器将启动。我将运行 Selenium 测试来点击各种站点以“预热它们”，因为复杂的专有 DB 框架需要预热和启动缓存。最初的几次尝试会失败。

一旦初始化，我们将通过电子邮件发送给团队，加拿大的一个人将运行一个不同的脚本式 Web 测试，这是我们的“冒烟测试”。如果有效（大约 40% 的成功率），该电子邮件将传递给测试团队以开始几个小时的更多测试。如果一切顺利，到周六凌晨 2 点，该站点就可以运行了。但这通常不会发生。某些小问题会被破坏，因为某些配置被遗忘或者文件未提交，或者有人错过了一个步骤。巨大的文件，没有移动部件的方法，此文件传输速度不快。

本地开发机器运行的是 Windows、Oracle JDK 和 Tomcat，以及一个特殊的 Java 应用程序来模拟应用程序服务器。对于生产环境，我们在具有不同 JDK 实现的 UNIX Java 应用程序服务器上运行。几乎从来没有顺利过。不同 JDK、应用程序服务器、内存、JMS、数据库连接和库问题存在太多奇怪的问题。有超过 20,000 个 Java 类，其中包含许多 Session 和 Entity EJB。唯一的好处是，我的团队开发的所有项目都具有良好的单元测试，并且一切都使用了良好的域建模。尽管面临巨大的截止日期，我们仍将代码覆盖率保持在 80% 以上，并使用了 FindBugs/PMD/CheckStyle。我们强制对所有模块进行同行评审，这非常有用，但如果没有自动化，确实会给流程增加一个手动步骤。我忘了提及我们有几个小时以上的 ANT 构建；我想我把它屏蔽了。

当你没有好的流程和一个平台来帮助你时，好的代码也会失败。
当你没有一个拥抱 DevOps、微服务而不是巨型单体架构的良好文化时，优秀的团队也会失败。