EASYOPS系列｜謹慎！勿讓持續傳遞變成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…如果有針對雲平台的軟體持續傳遞過程就更好了。你有彈性資源，有平穩的軟體更新能力，甚至還有實作雲端軟體傳遞的成熟方式，這些能力如果放着不用，那簡直太不明智了。這個有點像很多上雲的公司隻把雲當作自己的資料中心，這就有點大材小用了。

轉載于:https://my.oschina.net/easyops/blog/880817