你的持續交付能力用得還好嗎，比如頻繁釋出移動或雲應用的特性增強？還是恰好相反，快速釋出了帶漏洞的版本？
– 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研究院