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