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

拆開這個(gè)數(shù)字通常是IT領(lǐng)導(dǎo)者經(jīng)常碰到的問題，并且是談?wù)摽焖偌铀贂r(shí)最大的推銷來源。軟件交付的穩(wěn)定性如何？這些部署中有多少成功？什么是部署？

這些問題通常導(dǎo)致分析癱瘓，并且沒有任何變化。實(shí)際上，最常見的回應(yīng)始于：“我們不可能在我的公司實(shí)施類似的事情，因?yàn)椤蔽覀冎肋@是錯(cuò)誤的。傳統(tǒng)上以瀑布式方式交付的公司每月或每季度只進(jìn)行一次，腫的部署，這些公司正在成功過渡到快速部署，并發(fā)布了與其他團(tuán)隊(duì)類似的基準(zhǔn)數(shù)量。

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

基本原則

讓我們以一些關(guān)鍵原則為舞臺打下基礎(chǔ)，這些原則將闡明前進(jìn)的道路。他們是：

• 擁抱失敗

• 無懈可擊地分析故障

• 了解后快速修復(fù)故障

• 一直在迭代

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

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

如何開發(fā)軟件？

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

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

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

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

這些對話 總是 很有啟發(fā)性的，因?yàn)樵谶M(jìn)行一些初始對話后，放慢速度會(huì)變得很明顯。保持這些腦汁暢通，讓我們繼續(xù)。

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

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

• 學(xué)習(xí)如何編寫軟件的入門障礙是什么？

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

• 同事運(yùn)行您的演示代碼有多困難？

• 誰可以部署軟件？

• 與學(xué)習(xí)如何發(fā)布軟件相關(guān)的進(jìn)入障礙是什么？

• 工作分配到哪里？

• 功能討論在哪里進(jìn)行？

將事情推向高潮

至此，您可能已經(jīng)有了一份清單，其中列出了您已確定為需要改進(jìn)的地方。但是，您將重點(diǎn)放在哪里？默認(rèn)的趨勢是先清理商店，然后與外部團(tuán)隊(duì)合作以嘗試更好地整合。但是，實(shí)際上這是最不理想的操作，因?yàn)樗罱K會(huì)導(dǎo)致隔離孤島?？赡苓`反您的更好判斷，請先計(jì)劃集成。

您的第一步應(yīng)該集中在兩個(gè)目標(biāo)上。首先是將自己嵌入到開發(fā)工作流中……通過現(xiàn)有流程從開發(fā)中獲取工作項(xiàng)，并找到自己的擁護(hù)者。該倡導(dǎo)者將是您的“第一跟從者”，并將幫助您了解哪些更改在起作用，哪些無效，并且會(huì)提供有價(jià)值和誠實(shí)的反饋，這些反饋可能不是來自其他成員，不是因?yàn)樗麄儾辉诤?，而是因?yàn)樗麄兊木Ｗ⒂谄渌虑?。從小做起幾乎是必要的?/span>

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

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

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

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

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

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

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

前進(jìn)的道路很危險(xiǎn)，請選擇這些！

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

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

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

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

總結(jié)

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

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

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