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

初始化后，我们将通过电子邮件通知团队，加拿大的一个人将运行一个不同的脚本化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、微服务而不是巨型单体架构，优秀的团队也会失败。