这似乎是很久以前的事了，但就在几年前，我还在为一个大型系统集成商领导一个价值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 决策以及关键的数据库比较步骤。我们当时使用一个主要软件公司的专有垂直框架作为项目的基础。这涉及到手动运行 SQL 脚本，运行差异脚本，目视比较一些项目，检查版本控制清单，检查 Cruise Control 结果，JUnit / 代码覆盖率 HTML 和其他一些生成的报告。一位 UNIX 管理员会复制巨大的 EAR 文件、SQL 和大量的巨型 XML 文件。一旦完成，他们会运行许多 shell 脚本来修改一些内容，有时会使用环境变量。然后它们会被移动到一个特殊目录，Java 应用程序服务器会被停止，所有东西都会被备份。EAR 文件会被移动过去，数据源和其他配置会被复制和检查。数据库更改脚本会针对 Oracle 运行，并通过大量的 SQL 脚本更新/插入/删除元数据。服务器会启动。我运行 Selenium 测试来访问各个站点以“预热”它们，因为复杂的专有数据库框架需要缓存预热和启动。前几次尝试都会失败。

一旦初始化完成，我们就会给团队发送电子邮件，加拿大的一位同事会运行一个不同的脚本化网页测试，这是我们的“冒烟测试”。如果测试成功（大约 40% 的成功率），邮件会转交给测试团队，开始几个小时的进一步测试。如果一切顺利，到周六凌晨 2 点，网站就可以上线了。但这通常不会发生。总会有一些小问题出故障，因为配置中遗漏了什么，或者文件没有提交，或者有人漏掉了一个步骤。文件巨大，无法分块移动，这种文件传输速度不快。

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

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