DevOps實踐-VMware的DevOps轉型之旅
如今，大多數公司都在進行DevOps轉型，以采用更快的發布，提供更好的質量，提高團隊的靈活性，敏捷性并獲得更快的反饋。VMware的移動產品也不例外。我們兩年前就懷著同樣的目標開始了轉型。這篇文章將列出我們轉型中遇到的障礙，以及使我們前進的解決方案。
從兩年前就著眼于DevOps目標開始，我們就有了一些可用的初始要素。我們有敏捷的流程，運營團隊，自動化工具和可用的技術，但是這些都不是一個引擎。因此，我們開始進行更改。
拒絕改變
改變的不確定性，恐懼和懷疑是人的天性，這創造了拒絕的環境。最困難的任務之一是說服團隊實施新的變革，并推動文化轉變。
為了解決這個問題，我們從不斷的培訓，并要求團隊慢慢進行這些變更。此過程幫助團隊了解了DevOps采用的價值。此外，我們很幸運獲得管理團隊的支持。沒有他們的支持和配合，我們的DevOps變革將是不可能的。
功能交付
我們經歷的另一項是功能交付。團隊承受著不斷的壓力，要求他們用很少的時間交付新功能。他們專注于交付工作代碼，但不對質量負責。質量是一個單獨的質量工程（QE）團隊的責任。開發人員日夜工作，提供超出團隊能力的代碼，但是QE仍然發現很多缺陷。
在進行團隊流程調整以采用更改的同時，我們不想發生重大變化來破壞可為客戶提供價值的新功能。
那么，我們有什么選擇呢？第一步，我們將團隊的工作速度降低到其正常工作能力的50％，以確保他們有足夠的時間專注于更高質量的工作。其次，我們為團隊提供了重新制定和更改“完成”定義的時間，我們開始專注于根本原因分析，并專注于自動化以避免類似的問題和減少將來的問題。
技術債務
技術債務是軟件開發的組成部分。大多數擁有遺留代碼的團隊都有某種技術上的債務，我們也是如此。我們的大多數移動產品都有一定的技術債務。
由于我們將速度降低到以前的能力的50％，因此我們有一定的喘息空間來承擔較小的技術債務，這是在團隊給定速度下進行計劃的一部分。對于所有團隊來說，決定將開發速度降低一半是一個艱難的決定。我們與產品管理團隊緊密合作，優先處理技術債務和工程改進以及新功能，以確保我們的產品長期成功。
團隊結構
當我們開始DevOps轉型之旅時，QE團隊獨立于開發人員運作。質量工程師負責測試產品。但是，這種安排在DevOps結構中不太適合。
管理層意識到了這個問題，改變了團隊結構。質量團隊與開發團隊合并。每個人都專注于提供高質量的產品，而質量是團隊中每個人的責任。QE與開發人員結對，向相同的經理匯報工作，并在設計和開發開始時就致力于質量。我們創建了DevOps風格的團隊。DevOps團隊是功能齊全的團隊，能夠構建，測試，具有基礎架構和管理服務技能。如果您是像VMware這樣的大型組織，則無需為每個團隊創建最基本的技能，而可以繼續擁有一個平臺團隊來滿足關鍵項目和跨多個項目的共同需求。但是，請確保使每個團隊都能自行管理應用程序和服務。
技能和知識
當管理層更改團隊結構以使每個人對產品質量負責時，說起來容易做起來難。技能和產品知識方面存在差距。例如，開發人員不知道如何創建測試用例。QE團隊不了解產品代碼對代碼開發的貢獻。
為了解決這個問題，我們開始提高團隊技能和交叉技能。在代碼開發和開發人員方面進行QE培訓，以考慮質量，測試計劃，測試策略以及整體采用質量思維方式。這樣做的目的不是讓QE開始開發代碼，也不是讓開發人員開始全職測試，而是要獲得所需的技能以更加熟悉產品和代碼。此外，我們希望擁有編程方面的專業知識，以開始構建其團隊所需的工具和系統。知識共享，結對編程，跨團隊技能開發簡化了轉換的過程。
自動化
DevOps涉及整個SDLC生命周期中的早期反饋，而自動化在提供早期和一致的反饋中扮演著非常重要的角色。沒有自動化，就無法實現DevOps的發展。當我們開始時，就已經有了自動化，但是，自動化沒有得到有效利用。由于對自動化腳本缺乏信任，測試結果被忽略了，并且開發人員沒有為自動化編寫任何測試腳本（少數單元測試除外）。
我們做了什么？我們回顧了我們的自動化測試策略。為了向左移動，我們選擇了與開發人員所使用的接近的工具和技術，以便他們可以使用自己喜歡的語言，IDE和工具編寫測試腳本。這在很大程度上幫助了我們，開發人員逐漸能夠開始編寫測試腳本，質量工程師開始修復產品缺陷。它還為我們提供了測試自動化的穩定性。我們測試框架的更好的設計和架構使每個團隊成員都能夠為實現質量目標做出貢獻。
環境
自動化的瓶頸之一是按需測試環境的可用性，因為Workspace ONE是一個非常復雜的產品，并且具有許多相互依存關系。對于每個團隊來說，要在每次測試運行中按需創建這樣的環境并不容易。
這是我們的基礎架構團隊介入的地方，并開始從事一個項目，以便為每個團隊提供按需測試環境。整個解決方案基于自助服務門戶和REST API。我們所有人很容易采用和使用API與自動化集成并創建測試環境。
跨團隊協作
如上所述，Workspace ONE是一款非常復雜的產品，具有數百個相互依賴關系，并分為數百個模塊。團隊經常在孤島上工作，專注于自己的交付物，而沒有考慮共享最佳實踐或創建可重用的代碼。這不是一個容易解決的問題，需要文化上的轉變。
解決方案是什么？我們組成了一個小團隊，開始團隊之間的協調，調整發布周期，在團隊之間重用代碼并改善代碼文檔。示例之一是重新創建基于微服務體系結構的測試框架，以便每個團隊可以共享自己的代碼腳本以避免重復。成立了一個跨平臺團隊來分離和編寫可在產品線中使用的可重用代碼。
結論
通過應用上述解決方案，我們能夠做出許多積極的改變。去年，當我們回顧并評估了移動SDK的結果時，我們發現iOS的發布速度提高了50％，Android的發布速度提高了25％。計劃外的補丁和次要版本在iOS上降低了58％，在Android上降低了29％。我們減少了上報次數，提高了生產率，增加了團隊之間的協作和質量，以及許多其他無形的收益。
不要害怕變化。正如*馬丁·福勒（Martin Fowler）*所說
如果您害怕更改某些內容，則顯然設計不佳。
通過適當的規劃開始您的DevOps轉型，確保管理在您身邊，并且所有利益相關者都知道這是一段旅程而不是目的地。實施時請注意上述障礙，但請繼續學習并保持繼續學習。
