《謹慎！勿讓持續交付變成bug自動化發布》要點：
本文介紹了謹慎！勿讓持續交付變成bug自動化發布，希望對您有用。如果有疑問，可以聯系我們。
你的持續交付能力用得還好嗎,比如頻繁發布移動或云應用的特性增強?還是恰好相反,快速發布了帶漏洞的版本?
– Joel Shore
持續交付能讓交付流程跑得更快,但持續交付本身并不能為發布質量打包票.國外基于Jenkins持續集成和持續交付平臺的某技術提供商認為,如果發布質量沒有得到一定程度上的保障,軟件交付在速度上的快慢變化都沒有太大意義.
隨著DevOps興起以及新時代下的行業競爭日趨白熱化,開發敏捷性和交付速度漸漸跑到能力新高峰,但大家仍越來越需要更快速交付高質量軟件.位于加州的提供商CEO Sacha Labourey在接受我們專訪時談到了持續交付的新發展以及他的擔憂.
云和移動應用是怎么樣改變著持續軟件的交付規則?
Labourey：我們正經歷一段有趣的時光.我們認為IT行業應當加快開發和交付周期,來順應這個時代的要求.移動應用開發中,DevOps能讓你從故障發現和快速失敗中受益匪淺.云應用同理,它們都實現了發現過程和利用資源加速交付的能力.
你認為DevOps扮演著重要角色嗎?
Labourey：我們在很多組織中發現,許多公司并非被迫投入去做DevOps或持續集成.大家都認為移動需求大就做了移動應用,云需求大就做了云功能.問題是企業得學會預見技術的競爭戰場,清楚怎么樣才能快速改變和建立最佳實踐.也只有產生了類似念頭的時候,他們才會意識到當下要做的事已不同往昔那樣隨波逐流.
我們與很多開發團隊和DevOps團隊討論過,以便幫助普通企業能尋求到一些突破.討論結果大致是這樣：DevOps已經不單是IT系統在效率上的提升問題,而涉及到了將企業發展目標納入應用開發和交付的過程.許多企業仍然對這些變化視而不見,但轉型已經開始,避無可避,且勢不可擋.
DevOps團隊軟件持續交付方面最常見的錯誤是什么?
Labourey：不勞而獲就想解決困難才是最常見的錯誤.即使是新開的項目,也會面臨一些棘手的難題.代碼自動化構建實現起來很容易,難的是對項目做出恰到好處的測試、配置、部署,而想做到這些,就需要DevOps團隊投入.當團隊沒有決心做好這件事,結局就是得到一個被戲稱為“發布bug頗有效率的過程”.
這么說,那豈不是持續交付軟件產品,在某種情況下就是為了更快地發布bug?
Labourey：小步快跑的發展節奏沒有問題.我們討論業務節奏加快的可行性需要在速度與穩定安全找到個平衡點.改變迭代速度并不是說你寫代碼的速度一下子就提高了,這個要適可而止,換個說法：“更接近預期的安全速度”,這種描述可能更適合,對吧?以更短周期做出新版,看看哪些起作用,哪些不起作用,然后再決定具體的迭代方式.
軟件持續交付怎樣與DevOps在總體上做到互相配合?
Labourey：首先,DevOps是一條好路子.原先那幫支持DevOps和敏捷開發的人都應該自豪,這點讓人想起了上世紀90年代的開源思潮.不過,那時候的那群人基本都是不care企業生產概念的理想主義者.
就像Linux甚至今天的Microsoft,這些都彰顯著開源世界的勝利.開發方法論也是這樣.以前的發布周期都很長——都要好幾年.在21世紀初,敏捷開發那幫人根本感受不到關鍵軟件對在生產過程中運行關鍵應用的意義.當下,如果你沒有最起碼的敏捷開發或更進一步的團隊DevOps規劃,你就是遲到了,畢竟每家公司都應該懂得從軟件生產中創造商業價值.
你怎么向不了解DevOps持續交付的開發人員闡述這些道理?
Labourey：顯然,如果你還沒有移動化應用的持續交付流程,那這本身就是個bug…如果有針對云平臺的軟件持續交付過程就更好了.你有彈性資源,有平穩的軟件更新能力,甚至還有實現云端軟件交付的成熟方式,這些能力如果放著不用,那簡直太不明智了.這個有點像很多上云的公司只把云當作自己的數據中心,這就有點大材小用了.
原文來自微信公眾號：DevOps研究院
