[[344247]]

介紹
DevOps始于一個或兩個小型團隊進行持續集成（CI）的過程，它已被企業視為快速向客戶提供高質量并以客戶為中心的創新的手段。 但是，正在擴大其DevOps實施規模的組織發現他們的工具鏈很大，很笨拙—并且脫節。在您進行企業DevOps轉型的過程中，應盡早消除此瓶頸。 幸運的是，您可以確保團隊及其工具之間的協作與合作，而無需更改整個工具生態系統。關鍵是將您的工具集成在一起，使它們可以共享數據信息并使工作可見，但又不改變人們使用每種工具的方式。許多工具具有內置的集成，可讓您直接與其他工具共享數據。但是，如果不存在這樣的集成，則可以使它們集成，以便整理和共享信息。

DevOps協作
DevOps的主要宗旨是打破壁壘，消除孤島，并組建具備交付軟件所需的一切能力的團隊：開發功能，將其部署到生產中以及確保高質量和高可用性地進行維護。

由于許多組織都以DevOps的方式進行發展，并且針對DevOps市場的工具不斷增長，因此發現并肩工作的團隊使用不同的工具并不罕見。

每個團隊管理自己的管道，維護自己的待辦事項，并使用自己的測試工具，部署工具和監視工具。對于許多團隊來說，這很好。如果其他團隊使用替代產品，只要每個團隊使用他們認為最能滿足其需求的工具，對他們來說都沒有關系。

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

在改進和發展其DevOps實踐的同時，組織有時會遇到這樣一個情況，即一個團隊針對同一件事使用多個工具。測試工程師通常使用一種工具來管理其積壓和任務，而開發人員則使用另一種工具。這通常是組織的歷史產物，這些組織在質量保證和開發團隊之間進行了清晰的區分-瀑布式開發的有力指標-現在將他們的人員整合到同一團隊中。但是，各種專家繼續使用他們過去使用的工具。這導致團隊內部的溝通都被窒息的情況。

問題的規模
BizTechInsights在2018年對191位技術影響者和決策者的調查中，BizTechInsights報告說，有40％的受訪者表示他們當前的應用程序交付管理解決方案未與其他系統集成。 這會阻礙DevOps的工作，DevOps努力確定并消除交付管道中的瓶頸。 這些組織指出了最大的瓶頸。 在采用了應用程序交付管理解決方案的組織中，有38％的組織對此表示不滿意。 只有21％的人表示他們當前的系統可以充分滿足他們的需求

但是，好消息是這些組織認識到這是一個問題，并且愿意做一些-關于它的事情。所以，你可以做什么？

連接工具集
一種簡單的方法 一個簡單的解決方案是選擇一組工具并在整個組織中實施它們。每個人都必須使用相同的生命周期管理工具，相同的功能測試，性能測試和安全性測試工具，相同的部署自動化工具等。但這很幼稚，而用一組新工具替換現有工具的成本為令人望而卻步，因為：

• 在許可證和支持方面，許多組織仍在為他們現有的工具付費。無法保證他們提早終止合同將獲得退款。他們會結束 同時支付現有軟件和新軟件的費用。
• 從現有的DevOps管道中斷開現有工具的工作，并采用新軟件來替換它們的工作，可能會出乎意料地耗費大量時間和金錢。客戶對獲得軟件更新比對等待團隊重新設計其管道更感興趣。
• DevOps團隊應專注于為客戶提供價值。隨著團隊學習新生態系統的方法，引入新工具通常意味著引入新的缺陷和瓶頸。
• 即使選擇了一套工具，也無法保證這些工具能夠共享信息并為團隊提供他們所需的見解，以跟蹤投資，管理積壓和解決問題。

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

創建一個相互聯系的包容性系統
更好的方法是讓團隊選擇最適合他們的工具。如果他們選擇與組織保持一致，或者甚至選擇兩個緊密合作的團隊之間，那么這是正確的時機。但是他們應該謹慎處理，同時要記住重新設計流程和程序的潛在成本。 理想情況下，您的團隊應該選擇已經集成并且可以相互通信的工具。但這很少發生。取而代之的是引入一個集成的，相互連接的但松散耦合的DevOps工具集，該工具集通過提供必要的端到端通信和協作渠道并與團隊選擇的工具集成，從而增加了價值。這種方法有幾個優點：

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

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

結論
團隊需要擁有自主權，以決定最適合他們的工具集。同時，團隊之間需要相互合作，如果他們選擇的工具無法緊密集成，則會妨礙團隊內部和團隊之間的通信渠道。 最有效的解決方案是讓團隊選擇自己的工具，并同時采用互聯的DevOps工具集，該工具集提供端到端的必要溝通和協作渠道，并且與團隊已經使用的工具集成在一起。每個團隊決定自己喜歡的工作方式，同時其生成的信息會自動與其他團隊和高級經理共享。組織可以確保每個團隊都將最關鍵和戰略性的投資給予正確的優先級，并獲得對每個項目的狀態和進度的可見性，無論其使用何種工具。

正如文章所說的每個團隊使用的工具不一樣這很常見，實現工具鏈之間的集成能夠幫助我們實現端到端的溝通和協作。我們現在使用的DevOps工具鏈有哪些呢？ 在流水線方面我們會使用Jira+GitLab+Jenkins+SonarQube +Nexus/Artifactory+Docker + Kubernetes等等。