許多組織都在尋找一個(gè)可以購買和標(biāo)準(zhǔn)化的單一平臺(tái)，但團(tuán)隊(duì)經(jīng)常會(huì)在一個(gè)不適合他們的平臺(tái)上掙扎。

譯自 DevOps Toolchains Beat Off-the-Shelf Platforms 。

尋找企業(yè)級(jí) DevOps 平臺(tái)的浪潮正在形成，但有跡象表明，這些平臺(tái)在性能上無法勝過將最佳單項(xiàng)工具組合起來的 DevOps 工具鏈。平臺(tái)工程可能會(huì)進(jìn)一步擴(kuò)大平臺(tái)和工具鏈之間的差距，為開發(fā)人員提供定制的、針對(duì)組織的預(yù)組裝工具鏈。

DevOps 平臺(tái)的概念比 DevOps 早了幾年。當(dāng) DevOps 成為市場上必須具備的標(biāo)簽時(shí)，許多現(xiàn)有的用于工作項(xiàng)管理、版本控制和持續(xù)集成構(gòu)建的一體化工具與 DevOps 保持一致。

對(duì) DevOps 運(yùn)動(dòng)密切關(guān)注的人會(huì)明顯注意到，這些工具的功能組中缺乏“Ops”。這些平臺(tái)不包括運(yùn)行手冊(cè)、可觀測性或基礎(chǔ)設(shè)施管理等功能。

人們傾向于認(rèn)為，將這些工具貼上“DevOps”標(biāo)簽是一個(gè)諷刺的營銷策略。然而，使用 DevOps 這個(gè)名稱的想法是幫助人們看到該產(chǎn)品可以成為 DevOps 工具鏈的一個(gè)重要部分。

通用 DevOps 平臺(tái)通常涵蓋計(jì)劃、開發(fā)、版本控制和構(gòu)建，有些的覆蓋范圍比其他的小。平臺(tái)的范圍越廣，完成工作所需的努力就越大。

為了說明這一點(diǎn)，你可以創(chuàng)建一個(gè)基本上是執(zhí)行任意命令的任務(wù)運(yùn)行器的平臺(tái)。這可以滿足企業(yè)對(duì) DevOps 平臺(tái)的定義。你的部署流水線將包括一個(gè)命令序列，使用命令行界面和 API 調(diào)用來執(zhí)行每個(gè)步驟。這樣一個(gè)平臺(tái)的價(jià)值很低。

所有流行的 DevOps 平臺(tái)在工作項(xiàng)管理或持續(xù)集成構(gòu)建等領(lǐng)域都有核心優(yōu)勢。在核心之外，其功能就不那么有用了。這不是一個(gè)弱點(diǎn)，因?yàn)槌晒Φ慕M織使用 DevOps 平臺(tái)來建立基礎(chǔ)，然后用專業(yè)的工具來補(bǔ)充，這些工具可以提高他們交付軟件的能力。他們不依賴將其作為 DevOps 的唯一工具。

這就是為什么所有這些平臺(tái)都提供了集成和擴(kuò)展機(jī)制。

直覺和研究

當(dāng)你使用更多的專業(yè)化工具時(shí)，需要進(jìn)行一定程度的集成。組合后的功能集必須帶來生產(chǎn)力和性能改進(jìn)，以抵消互操作性工作。如果你使用單一的DevOps平臺(tái)，就不會(huì)有互操作性問題，但你的功能集將限于通用工具中可用的。

但是，與更豐富的功能集相比，互操作性問題有多大？

如果你創(chuàng)建一個(gè)由獨(dú)立的工作項(xiàng)管理、版本控制、構(gòu)建和部署工具組成的部署流水線，你可以形成一個(gè)整潔的順序工具鏈，每個(gè)階段都有清晰的交付。提交引用工作項(xiàng)。每個(gè)提交都會(huì)觸發(fā)構(gòu)建。構(gòu)建過程創(chuàng)建的工件被上傳到部署工具，并可以導(dǎo)致零接觸部署到第一個(gè)環(huán)境。

通過這種輕量級(jí)的交付，多個(gè)工具組成的工具鏈優(yōu)于通用平臺(tái)就不奇怪了。這是經(jīng)典的工具箱與瑞士軍刀的場景，只不過我們談?wù)摰氖菍?duì)軟件交付至關(guān)重要的工具。你可能會(huì)帶上一個(gè)瑞士軍刀去野營旅行以備不時(shí)之需。然而，如果你的 builder 到現(xiàn)場時(shí)除了一個(gè)小的多功能工具外別無他物，你會(huì)諒解他對(duì)結(jié)果的顧慮。

“2023 年持續(xù)交付報(bào)告”證實(shí)了我們的直覺。報(bào)告發(fā)現(xiàn)，如果你使用更多工具，你成為頂級(jí)表現(xiàn)者的可能性會(huì)加倍。你的前置時(shí)間會(huì)更短，部署頻率更高，服務(wù)恢復(fù)更快。報(bào)告發(fā)現(xiàn) CI/CD 工具預(yù)測較高的表現(xiàn)，并且使你成為低端表現(xiàn)者的可能性大大降低。

報(bào)告中的一個(gè)警示故事是，自托管太多 CI/CD 工具會(huì)降低性能。當(dāng)團(tuán)隊(duì)自托管超過兩個(gè) CI/CD 工具時(shí)，這一點(diǎn)顯而易見，表明運(yùn)營負(fù)擔(dān)變得分心。由于大多數(shù)這些工具都以托管解決方案的形式提供，遠(yuǎn)離自托管工具可以減輕負(fù)載。

平臺(tái)工程可以提供幫助

平臺(tái)工程與 DevOps 運(yùn)動(dòng)深度相關(guān)。該概念基于 Matthew Skelton 和 Manuel Pais 關(guān)于團(tuán)隊(duì)拓?fù)涞墓ぷ鳎渲衅脚_(tái)團(tuán)隊(duì)的目的是“使面向流的團(tuán)隊(duì)(如特性團(tuán)隊(duì))能夠相當(dāng)自治地交付工作”。

平臺(tái)工程團(tuán)隊(duì)通過抽象掉開發(fā)團(tuán)隊(duì)必須處理的某些復(fù)雜性，試圖減輕開發(fā)團(tuán)隊(duì)的認(rèn)知負(fù)擔(dān)。平臺(tái)團(tuán)隊(duì)可能關(guān)注的一個(gè)關(guān)鍵領(lǐng)域是部署流水線。假設(shè)開發(fā)人員可以訪問由 DevOps 平臺(tái)和許多最佳單項(xiàng)工具組成的順暢 DevOps 工具鏈。在這種情況下，他們可以在沒有互操作性和運(yùn)營負(fù)擔(dān)的情況下交付軟件。這使團(tuán)隊(duì)可以獲得“持續(xù)交付狀態(tài)”報(bào)告的積極益處，而不會(huì)產(chǎn)生不利影響。

內(nèi)部開發(fā)者平臺(tái)可以按需生成整個(gè)部署流水線，部署和基礎(chǔ)設(shè)施自動(dòng)化準(zhǔn)備就緒。開發(fā)人員可以創(chuàng)建流水線和項(xiàng)目骨架，然后開始開發(fā)第一個(gè)功能。你可能會(huì)稱之為“即時(shí) Hello World”，因?yàn)槟憧梢粤⒓磳⒖諔?yīng)用部署到生產(chǎn)環(huán)境。

與買下架的通用產(chǎn)品相比，內(nèi)部開發(fā)者平臺(tái)是針對(duì)組織需求定制的，并且可以響應(yīng)必要的變更。

根據(jù)我們對(duì) DevOps 工具鏈的評(píng)估，你可以看到為什么平臺(tái)工程存在于 48% 的高績效 DevOps 組織中，根據(jù) Puppet 的“平臺(tái)工程狀態(tài)報(bào)告”。

你需要一個(gè)工具鏈

在企業(yè)范圍采用工具鏈?zhǔn)且豁?xiàng)艱巨的任務(wù)。因此，許多組織正在尋找一個(gè)可以購買和標(biāo)準(zhǔn)化的單一平臺(tái)。這將提供低投資回報(bào)，因?yàn)閳F(tuán)隊(duì)難以在一個(gè)不適合他們的平臺(tái)上實(shí)現(xiàn)高性能。

DevOps 平臺(tái)很好地解決了經(jīng)過深入探索的問題，但在邊緣位置很淺。高績效者使用最佳單項(xiàng)工具創(chuàng)建 DevOps 工具鏈，以加速軟件交付。平臺(tái)工程團(tuán)隊(duì)可以通過在內(nèi)部開發(fā)者平臺(tái)中提供完善支持的 DevOps 工具鏈來平滑路徑。

本文使用 文章同步助手 同步