建站
咨詢
售后
建站咨詢
新聞中心
[[344247]]
成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都做網站、網站建設、外貿營銷網站建設、企業(yè)官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯(lián)網時代的忻州網站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！
介紹
DevOps始于一個或兩個小型團隊進行持續(xù)集成（CI）的過程，它已被企業(yè)視為快速向客戶提供高質量并以客戶為中心的創(chuàng)新的手段。 但是，正在擴大其DevOps實施規(guī)模的組織發(fā)現(xiàn)他們的工具鏈很大，很笨拙—并且脫節(jié)。在您進行企業(yè)DevOps轉型的過程中，應盡早消除此瓶頸。 幸運的是，您可以確保團隊及其工具之間的協(xié)作與合作，而無需更改整個工具生態(tài)系統(tǒng)。關鍵是將您的工具集成在一起，使它們可以共享數(shù)據信息并使工作可見，但又不改變人們使用每種工具的方式。許多工具具有內置的集成，可讓您直接與其他工具共享數(shù)據。但是，如果不存在這樣的集成，則可以使它們集成，以便整理和共享信息。
DevOps協(xié)作
DevOps的主要宗旨是打破壁壘，消除孤島，并組建具備交付軟件所需的一切能力的團隊：開發(fā)功能，將其部署到生產中以及確保高質量和高可用性地進行維護。
由于許多組織都以DevOps的方式進行發(fā)展，并且針對DevOps市場的工具不斷增長，因此發(fā)現(xiàn)并肩工作的團隊使用不同的工具并不罕見。
每個團隊管理自己的管道，維護自己的待辦事項，并使用自己的測試工具，部署工具和監(jiān)視工具。對于許多團隊來說，這很好。如果其他團隊使用替代產品，只要每個團隊使用他們認為最能滿足其需求的工具，對他們來說都沒有關系。
為什么重要？
盡管每個團隊都可以很好地發(fā)揮自己的作用，但團隊成員必須經常與其他團隊整合。當一個團隊提供由另一團隊使用的服務時，并非總是可以創(chuàng)建一個跨職能的端到端團隊，該團隊可以覆蓋從服務后端到前端用戶界面的所有內容。這兩個團隊將需要同步他們的工作，并能夠共享資產和信息。 例如，如果消費者團隊發(fā)現(xiàn)服務中的缺陷，而又無法現(xiàn)場修復，則必須記錄該缺陷。如果兩個團隊使用不同的缺陷跟蹤系統(tǒng)，則共享這些資產將是一個挑戰(zhàn)。一方面，該缺陷需要記錄在提供商的系統(tǒng)中，以便他們知道并可以修復。如果消費者團隊沒有提供者系統(tǒng)的登錄權限，甚至沒有訪問服務器的權限，則無法記錄缺陷，而且該缺陷也不會得到解決。在這種情況下，團隊將繼續(xù)依靠電子郵件以及其他不適合此目的的效率低下的協(xié)作工具。
在改進和發(fā)展其DevOps實踐的同時，組織有時會遇到這樣一個情況，即一個團隊針對同一件事使用多個工具。測試工程師通常使用一種工具來管理其積壓和任務，而開發(fā)人員則使用另一種工具。這通常是組織的歷史產物，這些組織在質量保證和開發(fā)團隊之間進行了清晰的區(qū)分-瀑布式開發(fā)的有力指標-現(xiàn)在將他們的人員整合到同一團隊中。但是，各種專家繼續(xù)使用他們過去使用的工具。這導致團隊內部的溝通都被窒息的情況。
問題的規(guī)模
BizTechInsights在2018年對191位技術影響者和決策者的調查中，BizTechInsights報告說，有40％的受訪者表示他們當前的應用程序交付管理解決方案未與其他系統(tǒng)集成。 這會阻礙DevOps的工作，DevOps努力確定并消除交付管道中的瓶頸。 這些組織指出了最大的瓶頸。 在采用了應用程序交付管理解決方案的組織中，有38％的組織對此表示不滿意。 只有21％的人表示他們當前的系統(tǒng)可以充分滿足他們的需求
但是，好消息是這些組織認識到這是一個問題，并且愿意做一些-關于它的事情。所以，你可以做什么？
連接工具集
一種簡單的方法 一個簡單的解決方案是選擇一組工具并在整個組織中實施它們。每個人都必須使用相同的生命周期管理工具，相同的功能測試，性能測試和安全性測試工具，相同的部署自動化工具等。但這很幼稚，而用一組新工具替換現(xiàn)有工具的成本為令人望而卻步，因為：
- 在許可證和支持方面，許多組織仍在為他們現(xiàn)有的工具付費。無法保證他們提早終止合同將獲得退款。他們會結束 同時支付現(xiàn)有軟件和新軟件的費用。
- 從現(xiàn)有的DevOps管道中斷開現(xiàn)有工具的工作，并采用新軟件來替換它們的工作，可能會出乎意料地耗費大量時間和金錢?？蛻魧Λ@得軟件更新比對等待團隊重新設計其管道更感興趣。
- DevOps團隊應專注于為客戶提供價值。隨著團隊學習新生態(tài)系統(tǒng)的方法，引入新工具通常意味著引入新的缺陷和瓶頸。
- 即使選擇了一套工具，也無法保證這些工具能夠共享信息并為團隊提供他們所需的見解，以跟蹤投資，管理積壓和解決問題。
如果要從頭開始組建一個新組織，則此方法可能會起作用。但是，這種情況多久發(fā)生一次？遷移到DevOps的大多數(shù)大型組織在工具，流程和過程上都有悠久的歷史和投資。這些只能逐漸更改。
創(chuàng)建一個相互聯(lián)系的包容性系統(tǒng)
更好的方法是讓團隊選擇最適合他們的工具。如果他們選擇與組織保持一致，或者甚至選擇兩個緊密合作的團隊之間，那么這是正確的時機。但是他們應該謹慎處理，同時要記住重新設計流程和程序的潛在成本。 理想情況下，您的團隊應該選擇已經集成并且可以相互通信的工具。但這很少發(fā)生。取而代之的是引入一個集成的，相互連接的但松散耦合的DevOps工具集，該工具集通過提供必要的端到端通信和協(xié)作渠道并與團隊選擇的工具集成，從而增加了價值。這種方法有幾個優(yōu)點：
- 集成工具集通常作為基于云的服務提供。沒有設置成本，也沒有基礎架構成本，并且可以輕松地使用該工具注冊新的團隊成員，并隨著系統(tǒng)使用量的增長對他們進行培訓。這些工具通常預先配置了所有必需的集成。
- 連接的工具集中的工具可以與團隊已經使用的工具集成。他們不會強制組織團隊使用工具的方式發(fā)生變化。連接的工具集也是可擴展的，因此您可以通過開放的API將它們與任何第三方甚至定制工具集成。
- 如果該工具更適合團隊，則它們也可以替代團隊現(xiàn)有的工具。例如，如果一個團隊對其現(xiàn)有的生命周期管理工具不滿意，或者根本不使用它，那么集成工具集將包括一個已經為企業(yè)DevOps團隊設計，和配置的生命周期管理工具。隨著業(yè)務的發(fā)展，您可以根據需要交換工具進出，這也可以保護您免受供應商鎖定。
- 它們使整個DevOps管道自動化，同時聚合來自以下位置的數(shù)據和見解整個生態(tài)系統(tǒng)，將它們呈現(xiàn)在易于使用的儀表板上，以供所有利益相關者查看。開發(fā)人員可以查看其管道的狀態(tài)，測試人員可以查看正在運行的測試，主管可以跟蹤產品組合的整體狀態(tài)，等等，而無需中斷現(xiàn)有流程。
- 在組織從舊版軟件交付方法過渡到通過DevOps進行敏捷，持續(xù)交付的過程中，可以使用一些框架來幫助組織。
在企業(yè)范圍內?？缮炜s敏捷框架（SAFe）可能是最著名的。連接和集成的工具集通常支持開箱即用的一個或多個框架。 –請注意，總是最好先選擇框架，然后再選擇工具，而不是根據您的工具選擇框架。選擇一個互連的集成工具集，該工具集可以支持將在未來幾年為您的組織提供支持的框架。
結論
團隊需要擁有自主權，以決定最適合他們的工具集。同時，團隊之間需要相互合作，如果他們選擇的工具無法緊密集成，則會妨礙團隊內部和團隊之間的通信渠道。 最有效的解決方案是讓團隊選擇自己的工具，并同時采用互聯(lián)的DevOps工具集，該工具集提供端到端的必要溝通和協(xié)作渠道，并且與團隊已經使用的工具集成在一起。每個團隊決定自己喜歡的工作方式，同時其生成的信息會自動與其他團隊和高級經理共享。組織可以確保每個團隊都將最關鍵和戰(zhàn)略性的投資給予正確的優(yōu)先級，并獲得對每個項目的狀態(tài)和進度的可見性，無論其使用何種工具。
正如文章所說的每個團隊使用的工具不一樣這很常見，實現(xiàn)工具鏈之間的集成能夠幫助我們實現(xiàn)端到端的溝通和協(xié)作。我們現(xiàn)在使用的DevOps工具鏈有哪些呢？ 在流水線方面我們會使用Jira+GitLab+Jenkins+SonarQube +Nexus/Artifactory+Docker + Kubernetes等等。
分享文章：DevOps工具鏈集成實現(xiàn)企業(yè)的端到端通信和協(xié)作
文章源于：http://www.5511xx.com/article/dpcddio.html
