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