感覺好像是很久以前的事了，但就在幾年前，我還在為一家大型系統整合商領導一個價值 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 測試來訪問各個站點以「預熱它們」，因為複雜的專有資料庫框架需要快取預熱和啟動。最初的幾次嘗試會失敗。

一旦初始化完成，我們將通過電子郵件通知團隊，加拿大的某個人將運行另一個腳本化的 Web 測試，這是我們的「煙霧測試」。如果成功（成功率約 40%），電子郵件將傳遞給測試團隊，開始幾個小時的額外測試。如果一切順利，到星期六凌晨 2 點，網站就可以上線了。但通常不會發生這種情況。一些小問題會被破壞，因為配置中遺忘了一些東西，或者檔案沒有提交，或者有人遺漏了一個步驟。巨大的檔案，無法移動小塊，這種檔案傳輸並不快。

本地開發機器運行的是 Windows、Oracle JDK 和 Tomcat，外加一個特殊的 Java 應用程式來模擬應用程式伺服器。對於生產環境，我們在 UNIX Java 應用程式伺服器上運行，使用不同實作的 JDK。幾乎從未順利過。JDK、應用程式伺服器、記憶體、JMS、資料庫連線和程式庫問題出現了許多奇怪的問題。有超過 20,000 個 Java 類別，其中包含許多 Session 和 Entity EJB。唯一的好處是，我的團隊開發的所有項目都具有良好的單元測試，並且一切都使用了良好的領域模型。儘管有嚴苛的截止日期，我們仍將程式碼覆蓋率保持在 80% 以上，並使用了 FindBugs/PMD/CheckStyle。我們強制要求所有模組進行同儕審查，這非常有用，但如果不自動化，這確實為流程增加了一個手動步驟。我忘了提，我們有幾個小時以上的 ANT 建置；我想我把它們封鎖了。

當你沒有好的流程和平台來幫助你時，好的程式碼也會失敗。
當你沒有擁抱 DevOps、微服務而非巨型單體式架構的良好文化時，優秀的團隊也會失敗。