一份良好架構加上兩份團隊合作。再加點兒自動化，然後攪拌就好了。
在你的職業生涯中，你一定會參與到一個龐大的軟體釋出中。這個軟體釋出可能帶有各種頑固 Bug 和複雜依賴關係，它需要整個團隊全天候工作。更不用提的是，一旦它投入生產，它還需要不停地打補丁。
「CODING 企業版」作為企業級軟體研發管理系統，助力團隊敏捷開發轉型升級。
程式碼釋出是軟體開發人員敏捷性的一個強有力的晴雨表。如果釋出過程不順暢，那麼每一次制定計劃、程式設計和測試的努力都是徒勞的。為了使釋出過程敏捷，部署自動化是關鍵。在開發階段早期就要將程式設計師和運維人員聚集在一起，進行持續整合和快速解決缺陷的練習。
將程式碼保持在可釋出狀態是敏捷開發的標誌。如果你在定下來要釋出時卻釋出不出來程式碼，那麼世界上所有的精益計劃和迭代開發都毫無意義。
成功的軟體釋出始於模組化架構
在所有軟體專案中，最好的情況是可以頻繁且順暢地釋出版本。通過構建（或重構）模組化架構，團隊可以使釋出成為他們敏捷文化的自然組成部分。在專案的早期，還不會有一個大的應用程式（如上面提到的龐然大物），就應該將其按模組化切分。將類似的特性分組到較小的應用程式或元件中，並且在每個應用程式和元件之間有清晰的 API 介面。這些 API 可以在每次構建中自動測試，以確保相容性，並降低軟體釋出中的風險。
模組化的體系架構意味著您不需要 “大爆炸”式地釋出整個軟體庫，而 API 契約使元件新老版本之間的相容變得容易。簡單地說，模組化的釋出只需要移動很少的元件。這可以簡化釋出流程。
成功的軟體釋出是由良好的關係驅動的
軟體開發很少在真空中完成。實際上，偉大的軟體開發涉及到整個團隊，從產品管理人員到運維人員。例如，運維團隊是向生產交付軟體的關鍵合作伙伴，因為他們幫助軟體抵達終端使用者。
開發團隊可以通過這些方面助力運維團隊：
-
為每個釋出版本製作釋出清單。運維團隊沒法總是像開發團隊那樣瞭解本次釋出的具體情況。
-
對於在釋出中解決的每個問題，提供一個問題跟蹤記錄和原始碼版本控制的連結，這樣如果在部署過程中出現問題，運維團隊就可以知道問題的來龍去脈。
-
有時，當將程式碼從開發環境推到定版環境時會出現問題。把這些問題解決掉，因為它們可能會在生產過程中再次出現。
-
部署故障發生時，一定要給運維團隊一個清晰的升級方案，以順利地解決問題。
反過來，運維團隊也可以通過如下方面幫助開發團隊：
-
當生產中出現問題時，花點時間去理解根本原因和解決方案。這樣在將來這些問題才能避免再次發生（或更優雅地處理）。將配置資料從生產環境遷移到定版環境和開發環境，以防止配置資料不同步。
-
隨著程式碼從開發環境轉移到釋出環境，再到生產環境，關鍵配置和使用者資料遷移的方式正好相反：從生產環境遷移到開發環境。做好這種雙向同步有助於開發環境更真實地模擬生產環境。這意味著在釋出日會有更少的Bug和“驚喜”。
「CODING 企業版」提供便捷的釋出管理，清晰每一次釋出交付物，方便運維團隊執行開發團隊的釋出計劃。
成功的軟體釋出很容易推動
自動化！自動化！自動化！
自動化釋出是改進發布文化的最好方法。如果今天你的釋出還不是自動化的，那你可以從自動化釋出到定版環境開始做起。一旦每個人都看到了它如此簡單，自然的步驟就是自動化釋出到生產部署。
如果你覺得釋出是困難的，那就把它作為一種經常性的練習——即使只是為了定版。讓開發團隊感到釋出的痛苦點將激發他們的創新能力，使釋出更容易，更自動化。
自動化測試和持續整合是驅動成功釋出的關鍵規程。確保構建時間和測試時間儘可能短，並且要記住易於驗證的構建更容易釋出。
偉大的軟體釋出是偉大的！
將程式碼保持在可釋出狀態是敏捷開發的標誌。
如果你不能快速釋出，你所有的精益計劃和迭代開發都毫無意義。
我們是怎麼做到的
我們發現，由於我們提供的是軟體即服務（SaaS），小步快跑的釋出模式是最容易管理的。對於可下載的產品，開發、運維和構建工程團隊之間的緊密協作將會有很長的路要走。這些團隊應該團結合作來完成自動化釋出，並主動地為即將到來的產品變更調整自動化釋出。 Atlassian 的許多團隊都將每一個成功的主線版本釋出到一個測試環境中。當到交付階段需要正式釋出版本，或者釋出給客戶時，這些團隊只需要按下按鈕，觸發自動化部署就可以了。
「CODING 企業版」作為企業級軟體研發管理系統，任務看板功能實現了 Epic \ user stories \ Sprint 等敏捷概念落地。
作為軟體開發人員，釋出應該是我們創新週期的重點。通過釋出，我們可以看到客戶與我們編寫的程式碼進行互動，並提供反饋。耶！讓釋出成為你工作日的一個自然部分，當程式碼從指間流淌出來，你會享受著這樣的滿足感：“這是我的程式碼！”
本文中文翻譯自原文：Three ingredients for great software releases 編譯者：程景天。