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