[[344247]]

介紹
DevOps始于一個(gè)或兩個(gè)小型團(tuán)隊(duì)進(jìn)行持續(xù)集成（CI）的過(guò)程，它已被企業(yè)視為快速向客戶(hù)提供高質(zhì)量并以客戶(hù)為中心的創(chuàng)新的手段。 但是，正在擴(kuò)大其DevOps實(shí)施規(guī)模的組織發(fā)現(xiàn)他們的工具鏈很大，很笨拙—并且脫節(jié)。在您進(jìn)行企業(yè)DevOps轉(zhuǎn)型的過(guò)程中，應(yīng)盡早消除此瓶頸。 幸運(yùn)的是，您可以確保團(tuán)隊(duì)及其工具之間的協(xié)作與合作，而無(wú)需更改整個(gè)工具生態(tài)系統(tǒng)。關(guān)鍵是將您的工具集成在一起，使它們可以共享數(shù)據(jù)信息并使工作可見(jiàn)，但又不改變?nèi)藗兪褂妹糠N工具的方式。許多工具具有內(nèi)置的集成，可讓您直接與其他工具共享數(shù)據(jù)。但是，如果不存在這樣的集成，則可以使它們集成，以便整理和共享信息。

DevOps協(xié)作
DevOps的主要宗旨是打破壁壘，消除孤島，并組建具備交付軟件所需的一切能力的團(tuán)隊(duì)：開(kāi)發(fā)功能，將其部署到生產(chǎn)中以及確保高質(zhì)量和高可用性地進(jìn)行維護(hù)。

由于許多組織都以DevOps的方式進(jìn)行發(fā)展，并且針對(duì)DevOps市場(chǎng)的工具不斷增長(zhǎng)，因此發(fā)現(xiàn)并肩工作的團(tuán)隊(duì)使用不同的工具并不罕見(jiàn)。

每個(gè)團(tuán)隊(duì)管理自己的管道，維護(hù)自己的待辦事項(xiàng)，并使用自己的測(cè)試工具，部署工具和監(jiān)視工具。對(duì)于許多團(tuán)隊(duì)來(lái)說(shuō)，這很好。如果其他團(tuán)隊(duì)使用替代產(chǎn)品，只要每個(gè)團(tuán)隊(duì)使用他們認(rèn)為最能滿(mǎn)足其需求的工具，對(duì)他們來(lái)說(shuō)都沒(méi)有關(guān)系。

為什么重要？
盡管每個(gè)團(tuán)隊(duì)都可以很好地發(fā)揮自己的作用，但團(tuán)隊(duì)成員必須經(jīng)常與其他團(tuán)隊(duì)整合。當(dāng)一個(gè)團(tuán)隊(duì)提供由另一團(tuán)隊(duì)使用的服務(wù)時(shí)，并非總是可以創(chuàng)建一個(gè)跨職能的端到端團(tuán)隊(duì)，該團(tuán)隊(duì)可以覆蓋從服務(wù)后端到前端用戶(hù)界面的所有內(nèi)容。這兩個(gè)團(tuán)隊(duì)將需要同步他們的工作，并能夠共享資產(chǎn)和信息。 例如，如果消費(fèi)者團(tuán)隊(duì)發(fā)現(xiàn)服務(wù)中的缺陷，而又無(wú)法現(xiàn)場(chǎng)修復(fù)，則必須記錄該缺陷。如果兩個(gè)團(tuán)隊(duì)使用不同的缺陷跟蹤系統(tǒng)，則共享這些資產(chǎn)將是一個(gè)挑戰(zhàn)。一方面，該缺陷需要記錄在提供商的系統(tǒng)中，以便他們知道并可以修復(fù)。如果消費(fèi)者團(tuán)隊(duì)沒(méi)有提供者系統(tǒng)的登錄權(quán)限，甚至沒(méi)有訪問(wèn)服務(wù)器的權(quán)限，則無(wú)法記錄缺陷，而且該缺陷也不會(huì)得到解決。在這種情況下，團(tuán)隊(duì)將繼續(xù)依靠電子郵件以及其他不適合此目的的效率低下的協(xié)作工具。

在改進(jìn)和發(fā)展其DevOps實(shí)踐的同時(shí)，組織有時(shí)會(huì)遇到這樣一個(gè)情況，即一個(gè)團(tuán)隊(duì)針對(duì)同一件事使用多個(gè)工具。測(cè)試工程師通常使用一種工具來(lái)管理其積壓和任務(wù)，而開(kāi)發(fā)人員則使用另一種工具。這通常是組織的歷史產(chǎn)物，這些組織在質(zhì)量保證和開(kāi)發(fā)團(tuán)隊(duì)之間進(jìn)行了清晰的區(qū)分-瀑布式開(kāi)發(fā)的有力指標(biāo)-現(xiàn)在將他們的人員整合到同一團(tuán)隊(duì)中。但是，各種專(zhuān)家繼續(xù)使用他們過(guò)去使用的工具。這導(dǎo)致團(tuán)隊(duì)內(nèi)部的溝通都被窒息的情況。

問(wèn)題的規(guī)模
BizTechInsights在2018年對(duì)191位技術(shù)影響者和決策者的調(diào)查中，BizTechInsights報(bào)告說(shuō)，有40％的受訪者表示他們當(dāng)前的應(yīng)用程序交付管理解決方案未與其他系統(tǒng)集成。 這會(huì)阻礙DevOps的工作，DevOps努力確定并消除交付管道中的瓶頸。 這些組織指出了最大的瓶頸。 在采用了應(yīng)用程序交付管理解決方案的組織中，有38％的組織對(duì)此表示不滿(mǎn)意。 只有21％的人表示他們當(dāng)前的系統(tǒng)可以充分滿(mǎn)足他們的需求

但是，好消息是這些組織認(rèn)識(shí)到這是一個(gè)問(wèn)題，并且愿意做一些-關(guān)于它的事情。所以，你可以做什么？

連接工具集
一種簡(jiǎn)單的方法 一個(gè)簡(jiǎn)單的解決方案是選擇一組工具并在整個(gè)組織中實(shí)施它們。每個(gè)人都必須使用相同的生命周期管理工具，相同的功能測(cè)試，性能測(cè)試和安全性測(cè)試工具，相同的部署自動(dòng)化工具等。但這很幼稚，而用一組新工具替換現(xiàn)有工具的成本為令人望而卻步，因?yàn)椋?/p>

• 在許可證和支持方面，許多組織仍在為他們現(xiàn)有的工具付費(fèi)。無(wú)法保證他們提早終止合同將獲得退款。他們會(huì)結(jié)束 同時(shí)支付現(xiàn)有軟件和新軟件的費(fèi)用。
• 從現(xiàn)有的DevOps管道中斷開(kāi)現(xiàn)有工具的工作，并采用新軟件來(lái)替換它們的工作，可能會(huì)出乎意料地耗費(fèi)大量時(shí)間和金錢(qián)?？蛻?hù)對(duì)獲得軟件更新比對(duì)等待團(tuán)隊(duì)重新設(shè)計(jì)其管道更感興趣。
• DevOps團(tuán)隊(duì)?wèi)?yīng)專(zhuān)注于為客戶(hù)提供價(jià)值。隨著團(tuán)隊(duì)學(xué)習(xí)新生態(tài)系統(tǒng)的方法，引入新工具通常意味著引入新的缺陷和瓶頸。
• 即使選擇了一套工具，也無(wú)法保證這些工具能夠共享信息并為團(tuán)隊(duì)提供他們所需的見(jiàn)解，以跟蹤投資，管理積壓和解決問(wèn)題。

如果要從頭開(kāi)始組建一個(gè)新組織，則此方法可能會(huì)起作用。但是，這種情況多久發(fā)生一次？遷移到DevOps的大多數(shù)大型組織在工具，流程和過(guò)程上都有悠久的歷史和投資。這些只能逐漸更改。

創(chuàng)建一個(gè)相互聯(lián)系的包容性系統(tǒng)
更好的方法是讓團(tuán)隊(duì)選擇最適合他們的工具。如果他們選擇與組織保持一致，或者甚至選擇兩個(gè)緊密合作的團(tuán)隊(duì)之間，那么這是正確的時(shí)機(jī)。但是他們應(yīng)該謹(jǐn)慎處理，同時(shí)要記住重新設(shè)計(jì)流程和程序的潛在成本。 理想情況下，您的團(tuán)隊(duì)?wèi)?yīng)該選擇已經(jīng)集成并且可以相互通信的工具。但這很少發(fā)生。取而代之的是引入一個(gè)集成的，相互連接的但松散耦合的DevOps工具集，該工具集通過(guò)提供必要的端到端通信和協(xié)作渠道并與團(tuán)隊(duì)選擇的工具集成，從而增加了價(jià)值。這種方法有幾個(gè)優(yōu)點(diǎn)：

• 集成工具集通常作為基于云的服務(wù)提供。沒(méi)有設(shè)置成本，也沒(méi)有基礎(chǔ)架構(gòu)成本，并且可以輕松地使用該工具注冊(cè)新的團(tuán)隊(duì)成員，并隨著系統(tǒng)使用量的增長(zhǎng)對(duì)他們進(jìn)行培訓(xùn)。這些工具通常預(yù)先配置了所有必需的集成。
• 連接的工具集中的工具可以與團(tuán)隊(duì)已經(jīng)使用的工具集成。他們不會(huì)強(qiáng)制組織團(tuán)隊(duì)使用工具的方式發(fā)生變化。連接的工具集也是可擴(kuò)展的，因此您可以通過(guò)開(kāi)放的API將它們與任何第三方甚至定制工具集成。
• 如果該工具更適合團(tuán)隊(duì)，則它們也可以替代團(tuán)隊(duì)現(xiàn)有的工具。例如，如果一個(gè)團(tuán)隊(duì)對(duì)其現(xiàn)有的生命周期管理工具不滿(mǎn)意，或者根本不使用它，那么集成工具集將包括一個(gè)已經(jīng)為企業(yè)DevOps團(tuán)隊(duì)設(shè)計(jì)，和配置的生命周期管理工具。隨著業(yè)務(wù)的發(fā)展，您可以根據(jù)需要交換工具進(jìn)出，這也可以保護(hù)您免受供應(yīng)商鎖定。
• 它們使整個(gè)DevOps管道自動(dòng)化，同時(shí)聚合來(lái)自以下位置的數(shù)據(jù)和見(jiàn)解整個(gè)生態(tài)系統(tǒng)，將它們呈現(xiàn)在易于使用的儀表板上，以供所有利益相關(guān)者查看。開(kāi)發(fā)人員可以查看其管道的狀態(tài)，測(cè)試人員可以查看正在運(yùn)行的測(cè)試，主管可以跟蹤產(chǎn)品組合的整體狀態(tài)，等等，而無(wú)需中斷現(xiàn)有流程。
• 在組織從舊版軟件交付方法過(guò)渡到通過(guò)DevOps進(jìn)行敏捷，持續(xù)交付的過(guò)程中，可以使用一些框架來(lái)幫助組織。

在企業(yè)范圍內(nèi)。可伸縮敏捷框架（SAFe）可能是最著名的。連接和集成的工具集通常支持開(kāi)箱即用的一個(gè)或多個(gè)框架。 –請(qǐng)注意，總是最好先選擇框架，然后再選擇工具，而不是根據(jù)您的工具選擇框架。選擇一個(gè)互連的集成工具集，該工具集可以支持將在未來(lái)幾年為您的組織提供支持的框架。

結(jié)論
團(tuán)隊(duì)需要擁有自主權(quán)，以決定最適合他們的工具集。同時(shí)，團(tuán)隊(duì)之間需要相互合作，如果他們選擇的工具無(wú)法緊密集成，則會(huì)妨礙團(tuán)隊(duì)內(nèi)部和團(tuán)隊(duì)之間的通信渠道。 最有效的解決方案是讓團(tuán)隊(duì)選擇自己的工具，并同時(shí)采用互聯(lián)的DevOps工具集，該工具集提供端到端的必要溝通和協(xié)作渠道，并且與團(tuán)隊(duì)已經(jīng)使用的工具集成在一起。每個(gè)團(tuán)隊(duì)決定自己喜歡的工作方式，同時(shí)其生成的信息會(huì)自動(dòng)與其他團(tuán)隊(duì)和高級(jí)經(jīng)理共享。組織可以確保每個(gè)團(tuán)隊(duì)都將最關(guān)鍵和戰(zhàn)略性的投資給予正確的優(yōu)先級(jí)，并獲得對(duì)每個(gè)項(xiàng)目的狀態(tài)和進(jìn)度的可見(jiàn)性，無(wú)論其使用何種工具。

正如文章所說(shuō)的每個(gè)團(tuán)隊(duì)使用的工具不一樣這很常見(jiàn)，實(shí)現(xiàn)工具鏈之間的集成能夠幫助我們實(shí)現(xiàn)端到端的溝通和協(xié)作。我們現(xiàn)在使用的DevOps工具鏈有哪些呢？ 在流水線方面我們會(huì)使用Jira+GitLab+Jenkins+SonarQube +Nexus/Artifactory+Docker + Kubernetes等等。