優(yōu)化您的“內(nèi)部開發(fā)循環(huán)”以提高開發(fā)速度
關(guān)鍵在于找到本地開發(fā)速度和容器優(yōu)勢之間的平衡，而使用合適的工具和實(shí)踐，這是可以實(shí)現(xiàn)的。
譯自O(shè)ptimize Your 'Inner Dev Loop' to Increase Developer Velocity，作者 Matt Voget。
就像每個(gè)流行文化都有一個(gè)辛普森一家笑話一樣，科技界的一切都有一個(gè) XKCD 漫畫。一個(gè)很好的例子是“編譯,”，來自 2007 年。
十七年后，編譯已經(jīng)有點(diǎn)不受歡迎了。但我們都知道這張漫畫現(xiàn)在會(huì)說什么：“我的代碼正在容器化?！?/p>
容器化在擴(kuò)展開發(fā)方面發(fā)揮了重要作用。它允許開發(fā)人員在開發(fā)的不同階段以及從本地機(jī)器到生產(chǎn)服務(wù)器創(chuàng)建一致的環(huán)境。
這種一致性消除了古老的“在我的機(jī)器上可以運(yùn)行”問題，并顯著減少了與配置相關(guān)的問題。
但它也帶來了新的問題。容器構(gòu)建和注冊(cè)表上傳對(duì)工程師來說純粹是停機(jī)時(shí)間。
容器化可能很慢，這會(huì)影響生產(chǎn)力。這種稅收通常用于運(yùn)行和測試代碼，然后在代碼發(fā)生更改時(shí)再次支付。你可以看到由此展開的問題。
圖片
情況并非總是如此。在沒有容器的情況下，傳統(tǒng)的開發(fā)循環(huán)更快，允許更高的速度和更多的迭代。
我們能否在不犧牲容器優(yōu)勢的情況下恢復(fù)這種速度？可以。
內(nèi)部和外部開發(fā)循環(huán)解釋
這里的問題在于“內(nèi)部開發(fā)循環(huán)”。內(nèi)部開發(fā)循環(huán)是開發(fā)人員在本地工作于功能或錯(cuò)誤修復(fù)時(shí)執(zhí)行的一系列活動(dòng)。它通常包括：
- 編寫或修改代碼
- 構(gòu)建應(yīng)用程序
- 運(yùn)行和測試更改
- 必要時(shí)調(diào)試
- 提交代碼
這個(gè)循環(huán)在一天中重復(fù)進(jìn)行，其效率極大地影響了開發(fā)人員的生產(chǎn)力。這個(gè)循環(huán)越快越流暢，開發(fā)人員可以進(jìn)行的迭代次數(shù)就越多，從而更快地解決問題和開發(fā)功能。
相比之下，“外部開發(fā)循環(huán)”涵蓋了更廣泛的開發(fā)生命周期，包括：
- 規(guī)劃和任務(wù)分配
- 代碼審查和協(xié)作
- 持續(xù)集成和部署
- 暫存和生產(chǎn)發(fā)布
- 監(jiān)控和反饋收集
容器化的優(yōu)勢通過確保環(huán)境一致性和簡化部署而累積到外部開發(fā)循環(huán)中。但它給內(nèi)部開發(fā)循環(huán)帶來了摩擦。構(gòu)建容器并等待它們啟動(dòng)所花費(fèi)的時(shí)間會(huì)降低開發(fā)人員高效編碼所需的迭代速度。
在容器化之前，內(nèi)部開發(fā)循環(huán)可能看起來像這樣：
圖片
因此，在傳統(tǒng)的內(nèi)部開發(fā)循環(huán)中，我們每次開發(fā)迭代只需 5 分多鐘，只有 10 秒的“稅收”停機(jī)時(shí)間?；仡櫲萜骰姹?，這延長到了 9 分多鐘，其中近一半是“稅收”。
如果開發(fā)人員每天編碼 6 個(gè)小時(shí)，我們從容器化遷移到容器化后，迭代次數(shù)從 70 次減少到 40 次。在為期兩周的沖刺中，這將損失 300 個(gè)循環(huán)。
因此，優(yōu)化容器化環(huán)境中的內(nèi)部開發(fā)循環(huán)對(duì)于保持高開發(fā)速度至關(guān)重要。
降低內(nèi)部開發(fā)循環(huán)的停機(jī)時(shí)間稅
在容器化環(huán)境中簡化內(nèi)部開發(fā)循環(huán)是奪回失去速度的關(guān)鍵。我們必須找到方法來最大限度地減少容器化和部署帶來的“稅收”，同時(shí)保留容器提供的一致性和可移植性優(yōu)勢?，F(xiàn)代工具和實(shí)踐在這里發(fā)揮作用。
一種越來越流行的方法是本地到遠(yuǎn)程開發(fā)。這種方法允許開發(fā)人員在本地運(yùn)行代碼，同時(shí)無縫連接到遠(yuǎn)程 Kubernetes 集群。像 Ambassador 的Telepresence這樣的工具使開發(fā)人員能夠像本地機(jī)器是遠(yuǎn)程集群的一部分一樣進(jìn)行編碼。
這個(gè)想法很簡單但很強(qiáng)大：開發(fā)人員無需為每次代碼更改構(gòu)建和部署容器，而是可以在本地運(yùn)行一個(gè)正在開發(fā)的服務(wù)，并使其實(shí)時(shí)與遠(yuǎn)程集群中的其他服務(wù)交互。這種方法提供了幾個(gè)優(yōu)勢：
- 更快的反饋循環(huán)：開發(fā)人員可以立即看到其更改的影響，而無需等待其完整應(yīng)用程序容器化和部署。
- 熟悉的本地開發(fā)：工程師可以使用他們喜歡的工具和 IDE 來保持生產(chǎn)力。
- 訪問遠(yuǎn)程資源：開發(fā)人員可以像訪問本地資源一樣與遠(yuǎn)程集群中的數(shù)據(jù)庫、微服務(wù)和其他資源進(jìn)行交互。
- 減少資源使用：需要更少的遠(yuǎn)程開發(fā)環(huán)境，這可能導(dǎo)致成本節(jié)省。
- 協(xié)作開發(fā)：由于個(gè)人攔截等功能，團(tuán)隊(duì)可以在同一個(gè)集群上同時(shí)工作，而不會(huì)互相干擾。
采用這些工具和實(shí)踐可以顯著減少內(nèi)部開發(fā)循環(huán)的“稅收”。讓我們用這種優(yōu)化方法重新審視我們之前的示例：
圖片
在這種優(yōu)化方案中，我們將迭代時(shí)間縮短到大約 6 分鐘，只有大約 30 秒的停機(jī)時(shí)間稅。這意味著在 6 小時(shí)的編碼時(shí)間內(nèi)大約可以進(jìn)行 60 次迭代——這比容器化版本有了實(shí)質(zhì)性的改進(jìn)，并且更接近我們最初的預(yù)容器速度。如上所示，使用本地測試，開發(fā)人員循環(huán)比傳統(tǒng)循環(huán)略長，但仍然比常規(guī)容器循環(huán)快得多，并且它包含容器化的優(yōu)勢。雙贏！
目標(biāo)不是放棄容器——它們?cè)跀U(kuò)展和生產(chǎn)方面的優(yōu)勢太寶貴了。相反，混合方法可以將本地開發(fā)的速度與容器化環(huán)境的一致性和可靠性相結(jié)合。
通過專注于優(yōu)化內(nèi)部開發(fā)循環(huán)，我們可以幫助開發(fā)人員恢復(fù)他們失去的速度，從而導(dǎo)致更多迭代、更快的功能開發(fā)，以及最終更快地獲得更好的軟件。關(guān)鍵是找到本地開發(fā)速度與容器化優(yōu)勢之間的平衡——有了合適的工具和實(shí)踐，這種平衡是可以實(shí)現(xiàn)的。
最終，您的開發(fā)過程可以如此流暢，以至于您甚至沒有時(shí)間在容器化時(shí)查看 XKCD。
