一次又一次，我們聽說公司借助DevOps實現(xiàn)了快速加速。公司正在以每天的部署量來贊譽成功，共享每天10、50甚至100個部署的新基準。在諸如LinkedIn，Netflix，Etsy，F(xiàn)acebook等更成熟的組織中，這個數(shù)字是驚人的1,000多個數(shù)字。但是，這到底意味著什么？

拆開這個數(shù)字通常是IT領導者經(jīng)常碰到的問題，并且是談論快速加速時最大的推銷來源。軟件交付的穩(wěn)定性如何？這些部署中有多少成功？什么是部署？

這些問題通常導致分析癱瘓，并且沒有任何變化。實際上，最常見的回應始于：“我們不可能在我的公司實施類似的事情，因為……”我們知道這是錯誤的。傳統(tǒng)上以瀑布式方式交付的公司每月或每季度只進行一次，腫的部署，這些公司正在成功過渡到快速部署，并發(fā)布了與其他團隊類似的基準數(shù)量。

那么如何才能成功開始交付軟件？沒有單一的銀彈或魔杖，但是有一種相當規(guī)范的方法可以實現(xiàn)我們的快速交付目標。讓我們深入研究一下入門方法。

基本原則

讓我們以一些關鍵原則為舞臺打下基礎，這些原則將闡明前進的道路。他們是：

• 擁抱失敗

• 無懈可擊地分析故障

• 了解后快速修復故障

• 一直在迭代

簡而言之，目標應該是快速部署，快速失敗，快速學習和快速改進。 這是一項永無止境的任務，因此應如此考慮。太多次，一個項目被啟動以開始執(zhí)行這些任務，并且不可避免地該項目結束。除非持續(xù)改進成為交付的核心租戶，否則任何努力都有可能隨著時間的流逝而瓦解。

牢記這些規(guī)則，讓我們繼續(xù)。

如何開發(fā)軟件？

順便說一下，第一站不在交付組織內，而在開發(fā)組織內。這就是 與DevOps經(jīng)常討論的共情的地方 。我們首先需要確保提供功能的開發(fā)人員具備成功的條件。

如何開發(fā)軟件？進入生產(chǎn)流程真正意味著什么？問自己一些問題，例如：代碼如何引入源代碼樹？接受該代碼是什么樣的？（例如：是否有代碼格式化準則，是否需要測試等）

一旦理解了這一點，關鍵就是為將代碼推進到下一個交付階段而存在的大門。這是瓶頸經(jīng)常存在的地方，并且經(jīng)常具有存在的有效歷史案例。通常，這是為了嘗試通過引入檢查點來提高質量，但是這些檢查點通常是人為驅動的，并且總是會包含其自身的缺陷。

重要的是要區(qū)分代碼的交付或功能的交付與軟件本身的交付。兩者都很重要，如下一節(jié)所述，但是同一枚硬幣的兩側通常是分開的。在整個系統(tǒng)的上下文中，需求是相同的：通過取消流程中的步驟（無需不必要的增值，過時的痕跡）或引入自動化流程來尋找減少摩擦的機會。

這些對話 總是 很有啟發(fā)性的，因為在進行一些初始對話后，放慢速度會變得很明顯。保持這些腦汁暢通，讓我們繼續(xù)。

以下是一些要記住的問題：

• 誰可以編寫軟件？大家？

• 學習如何編寫軟件的入門障礙是什么？

• 向同事展示工作代碼有多困難？

• 同事運行您的演示代碼有多困難？

• 誰可以部署軟件？

• 與學習如何發(fā)布軟件相關的進入障礙是什么？

• 工作分配到哪里？

• 功能討論在哪里進行？

將事情推向高潮

至此，您可能已經(jīng)有了一份清單，其中列出了您已確定為需要改進的地方。但是，您將重點放在哪里？默認的趨勢是先清理商店，然后與外部團隊合作以嘗試更好地整合。但是，實際上這是最不理想的操作，因為它最終會導致隔離孤島。可能違反您的更好判斷，請先計劃集成。

您的第一步應該集中在兩個目標上。首先是將自己嵌入到開發(fā)工作流中……通過現(xiàn)有流程從開發(fā)中獲取工作項，并找到自己的擁護者。該倡導者將是您的“第一跟從者”，并將幫助您了解哪些更改在起作用，哪些無效，并且會提供有價值和誠實的反饋，這些反饋可能不是來自其他成員，不是因為他們不在乎，而是因為他們的精力專注于其他事情。從小做起幾乎是必要的。

在大多數(shù)情況下，提到DevOps時都會出現(xiàn)同理心。無論您為改善問題做出何種努力，開發(fā)人員生活中遇到的任何摩擦都會極大地影響您在任何實際變更中的成功。例如：更改基礎的票務平臺以使所有人都能更好地進行交流可能會比較有利，但是如果您破壞了現(xiàn)有的交付渠道，結交新朋友的幾率可能會下降。

與倡導工作，堅定發(fā)展報告如何發(fā)放到你的團隊，反之亦然，并運行它 通過了戰(zhàn)書。不要忘記應用基本規(guī)則…… 快速部署，快速失敗，快速學習和快速改進。 快速修復容易的工藝孔。請記住在任何給定時間引入的更改量，不要害怕進行更改，還要與更改保持一致并進行衡量。這將為持續(xù)和長期的流程改進設定適當?shù)幕{。

同樣，通過第一個過程進行實際項目。早期的勝利可以是確保開發(fā)人員能夠以最小的努力運行任何版本的代碼（git checkout，主要版本，都沒有關系）。

這使我可以運行其他同事的代碼來測試修復程序，確認錯誤或其他。通過具有運行任意代碼的能力，協(xié)作可以最接近于代碼，并且可以更早地解決直至后期部署階段的問題數(shù)量。這可能意味著暫存環(huán)境。這可能意味著本地開發(fā)環(huán)境。但是，解決開發(fā)人員如何運行代碼的較小任務成為生產(chǎn)交付管道如何運行的測試床。

當您在過程和工具中都發(fā)現(xiàn)故障時，在分析和處理故障時毫無責任是至關重要的。盡早有很多，因此盡早定調至關重要。John Allspaw在討論獎勵措施時在其文章中談到了這一點：“因為認為自己將受到譴責的工程師不愿提供必要的詳細信息，以了解故障的機理，病理和操作。對事故如何發(fā)生的了解不足，只能保證會再次發(fā)生。如果不是與原始工程師一起，將來還會有另一個”。

另一個經(jīng)常被忽視的問題是如何實現(xiàn)這些解決方案。這些過程的修復不能由一個人或以自上而下的方式進行。相反，團隊的所有成員必須是擁有解決方案的一部分。時間和鼓勵將花很長的時間。

最后，部署。該項目的重點是部署代碼。到目前為止，已完成的工作將主要集中在開發(fā)與運營之間的交互上，但是可以肯定的是，雙方都需要完成工作。在您可以每天進行部署而不會造成任何損壞之前，這應該是您的目標。無論您是否已經(jīng)知道結果，每天都要嘗試部署代碼。每天選擇以下兩項要解決的問題之一：該過程失敗或手動執(zhí)行。重復此過程，直到您每天可以使用最少數(shù)量的命令進行部署（最佳情況：單個命令）。

前進的道路很危險，請選擇這些！

當您沿著這條道路前進時，會有兩個主題一次又一次出現(xiàn)。首先與溝通有關。隨著時間的流逝，部署過程可能會變得更快或更簡化，但始終存在溝通障礙會給最佳團隊帶來挑戰(zhàn)的方式。

第二個總是與工具差異有關。一旦工程師大為鼓舞，需要實施工具，所有人員和流程問題將成為次要問題。由于這些工具實際上需要參與組織內的通信流以促進軟件交付，因此通常會陷入困境。

為此，有兩種非常有用的工具值得記?。篊hatOps 和Workflow。這兩個主題均應專門用于其自身的整個章節(jié)，但簡而言之，這是應該磨合您的調色板的兩件事。

請記?。哼@不是一種工具。這些工具是達到目的的一種手段。人員和流程必須是此對話的一部分。ChatOps支持創(chuàng)建和驅動開發(fā)的通信和協(xié)作。工作流使圍繞基礎架構流程的協(xié)作成為可能。這兩個都將變得至關重要。

總結

要取得成功，我們作為技術專家需要了解組織中正在發(fā)生的事情，技術工作如何幫助交付，所部署的技術如何被消費以及由誰使用。沒有這種了解，我們只會將工具丟在一個問題上，并且常常使事情變得復雜。這些工具可能會卡住東西或成為架子商品，因為沒有人準備實施它們。在當今快速發(fā)展，精益的業(yè)務中，沒有時間崩潰。

您知道您的團隊如何圍繞軟件進行交付和協(xié)作嗎？您的團隊與提供服務的團隊之間是否建立了緊密的反饋循環(huán)？您的移動速度很快，并且修復速度更快嗎？

如今，團隊如何交付軟件已迅速被公認為是市場差異化因素。這一過程既不容易也不容易，但是它將使您的組織為行業(yè)的快速發(fā)展的下一階段做好準備。