這似乎是很久以前的事了，但就在幾年前，我還在為一個大型系統整合商領導一個價值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、微服務而不是巨大單體的好文化時，好的團隊也會失敗。