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