前面一章節(jié)我們已經(jīng)了解了Agile,CI/CD,DevOps，作為DevOps的起點(diǎn)，對(duì)于一個(gè)團(tuán)隊(duì)，如何開(kāi)始自己的持續(xù)集成？根據(jù)我的經(jīng)驗(yàn)，列出了一下需要考慮的點(diǎn)
1. 代碼管理/分支策略
- 代碼托管在哪里？
- 使用git or svn?
- 分支策略/分支模型？
- CI 服務(wù)可以訪問(wèn)您的代碼庫(kù)嗎？
- 代碼結(jié)構(gòu)如何？需要一個(gè)庫(kù)，還是多個(gè)庫(kù)？
- 版本號(hào)定義？
- 依賴(lài)管理？命名規(guī)則？
- Code Review ?
2. 持續(xù)集成服務(wù)器
- 選好你需要的CI server了嗎？ jenkins, Teamcity,GoCD or AuzreDevOps
- CI Server 使用的學(xué)習(xí)
- CI Server 如何部署，需要多少資源，需要多少并發(fā)job ?
- Pipeline編寫(xiě)，如何標(biāo)準(zhǔn)化？是否需要參數(shù)化？
- 與代碼倉(cāng)庫(kù)，制品庫(kù)集成？
- 靜態(tài)代碼檢查？SonarQube
- 多分支/多個(gè)倉(cāng)庫(kù)，相互依賴(lài)？
3. 制品庫(kù)
- 選擇合適的制品庫(kù)服務(wù)器 (jar, npm, nuget, Docker or other package ?)
- 制品的版本？ 如何與code commit id 關(guān)聯(lián)？
- 制品庫(kù)保存策略/tag 管理
4. 測(cè)試類(lèi)型
CI階段除了保證代碼沒(méi)有沖突，編譯通過(guò)之外，最重要的就是測(cè)試 。每次代碼變更后，我們需要自動(dòng)運(yùn)行測(cè)試用例。
在初始階段并不需要實(shí)現(xiàn)所有的測(cè)試類(lèi)型。一開(kāi)始可以以單元測(cè)試入手，隨著時(shí)間擴(kuò)展覆蓋面。
- 單元測(cè)試：范圍非常小，驗(yàn)證每個(gè)獨(dú)立方法級(jí)別的操作。
- 集成測(cè)試：保證模塊間運(yùn)行正常，包括多個(gè)模塊、多個(gè)服務(wù)。
- 驗(yàn)收測(cè)試：與集成測(cè)試類(lèi)似，但是僅關(guān)注業(yè)務(wù) case，而不是模塊內(nèi)部本身。
- UI 測(cè)試：從用戶(hù)的角度保證呈現(xiàn)正確運(yùn)行。
并不是所有的測(cè)試都是對(duì)等的，實(shí)際運(yùn)行中可以做些取舍。
4級(jí)測(cè)試規(guī)劃
image.png
- 單元測(cè)試實(shí)現(xiàn)起來(lái)既快成本又低，因?yàn)樗鼈冎饕菍?duì)小代碼塊進(jìn)行檢查。
- UI 測(cè)試實(shí)施起來(lái)很復(fù)雜，運(yùn)行起來(lái)很慢，因?yàn)樗ǔＰ枰獑?dòng)一個(gè)完整的環(huán)境以及多個(gè)服務(wù)來(lái)模擬瀏覽器或移動(dòng)行為。實(shí)際情況可能希望限制復(fù)雜的 UI 測(cè)試的數(shù)量，并依賴(lài)基礎(chǔ)上良好的單元測(cè)試來(lái)快速構(gòu)建，并盡快獲得開(kāi)發(fā)人員的反饋。
- 單元測(cè)試前期投入少，短期內(nèi)可以看到效果，對(duì)開(kāi)發(fā)人員要求高；UI測(cè)試前期人員成本投入大，需要很長(zhǎng)時(shí)間看到效果
代碼覆蓋率
- 使用代碼覆蓋率查找未測(cè)試的代碼。一旦您采用了自動(dòng)化測(cè)試，最好將它與一個(gè)測(cè)試覆蓋工具結(jié)合起來(lái)，幫助了解測(cè)試套件覆蓋了多少代碼庫(kù)。代碼覆蓋率定在 80%以上是很好的，但要注意不要將高覆蓋率與良好的測(cè)試套件混淆。代碼覆蓋工具將幫助您找到未經(jīng)測(cè)試的代碼，但在一天結(jié)束的時(shí)候，測(cè)試的質(zhì)量會(huì)產(chǎn)生影響。如果剛開(kāi)始，不要急于獲得代碼庫(kù)的 100%覆蓋率，而是使用測(cè)試覆蓋率工具來(lái)找出應(yīng)用程序的關(guān)鍵部分，這些部分還沒(méi)有測(cè)試并從那里開(kāi)始。
- 重構(gòu)是一個(gè)添加測(cè)試的機(jī)會(huì)。如果您將要對(duì)應(yīng)用程序進(jìn)行重大更改，那么應(yīng)該首先圍繞可能受到影響的特性編寫(xiě)驗(yàn)收測(cè)試。這將為您提供一個(gè)安全網(wǎng)，以確保在重構(gòu)代碼或添加新功能后，原始行為不會(huì)受到影響。
5. 測(cè)試/部署環(huán)境準(zhǔn)備
- 測(cè)試需要多少資源 ？
- 編寫(xiě)自動(dòng)化部署腳本？ Python,shell, powershell, or ansible ?
- 多環(huán)境/多分支 配置？
6. 團(tuán)隊(duì)CI文化
- 當(dāng)團(tuán)隊(duì)實(shí)踐 CI 時(shí)，需要了解分支模型，按照定義的commit 策略，進(jìn)行頻繁提交
- 提交沖突了，如何處理？
- 怎么反饋沖突 或者build break ? 誰(shuí)處理？
- 推廣普及CI文化盡早集成。如果很長(zhǎng)時(shí)間不合并代碼，代碼沖突的風(fēng)險(xiǎn)就越高，代碼沖突的范圍就越廣。如果發(fā)現(xiàn)某些分支會(huì)影響已經(jīng)存在的分支，需要增加發(fā)布關(guān)閉標(biāo)簽，避免發(fā)布時(shí)兩個(gè)分支沖突。保證編譯時(shí)時(shí)刻刻暢通。一旦發(fā)現(xiàn)任何編譯問(wèn)題，立刻修復(fù)，否則可能會(huì)帶來(lái)更多的錯(cuò)誤。測(cè)試套件需要盡快反饋測(cè)試結(jié)果，或者優(yōu)先返回短時(shí)間測(cè)試（單元測(cè)試）的結(jié)果，否則開(kāi)發(fā)者可能就切換回開(kāi)發(fā)了。一旦編譯出錯(cuò)，需要通知給開(kāi)發(fā)者，或者更進(jìn)一步給出一個(gè) dashboard，每個(gè)人都可以在這里查看編譯結(jié)果。把測(cè)試用例納入流程的一部分。確保每個(gè)分支都有自動(dòng)化測(cè)試用例。似乎編寫(xiě)測(cè)試用例拖慢了項(xiàng)目節(jié)奏，但是它可以減少回歸時(shí)間，減少每次迭代帶來(lái)的 bug。而且每次測(cè)試通過(guò)后，將會(huì)非常有信息合并到主干分支，因?yàn)樾略龅膬?nèi)容不影響以前的功能。修 bug 的時(shí)候編寫(xiě)測(cè)試用例。把 bug 的每個(gè)場(chǎng)景都編寫(xiě)成測(cè)試用例，避免再次出現(xiàn)。
歡迎關(guān)注我的微信公眾號(hào) - DevOps實(shí)踐之路
