持續集成和持續交付
云計算團隊 2020-03-16
在DevOps最佳實踐里面分為了研發管理，持續交付和技術運營幾個關鍵的過程域。但是在實踐的過程中，最容易出現問題的不是單個技術點，而是跨域的協同問題，或者說研發過程管理和持續集成交付本身就是密不可分的兩個部分，我們只是為了容易理解和學習將其劃分為了不同的過程域而已。
任何一次新的編譯構建部署完成后都涉及到測試人員測試，測試人員測試出問題后又會提交Bug，開發人員修改Bug后檢入代碼，等待下一次打包部署以形成多次迭代。整個過程最好方式就是要盡量減少大量的人工溝通協同，而是應該通過工具鏈協同來完成。
對于傳統的持續集成，一般最佳實踐為每天晚上進行自動化構建和冒煙測試，而對于當期的DevOps過程，在設計完流水線后，可以手工去啟動流水線作業，也可以自動去執行流水線，流水線執行時間頻度也可以進一步縮短，假設我們每2個小時自動化的執行一次流水線作業，我們以此場景來做進一步梳理。
流水線增加啟動檢查節點-雖然2小時執行一次流水線，但是在執行前先進行啟動前檢查，如果在最近2個小時內沒有新代碼check in，那么不執行流水線。其次，如果上一次流水線執行實例還處于待處理或未關閉狀態的時候，同樣也不執行流水線作業而直接跳過。
是否需要人工驗證：流水線打包部署包括兩個方面，一個是新功能提交或新bug解決，只有這種情況才需要人工驗證。因此一次流水線執行如果沒有新需求或Bug狀態變化，那么應該直接跳過人工驗證節點并關閉。反之，則應該跳轉到待人工驗證環節。
需求和缺陷的管理：注意新需求和新缺陷都應該提交，都有狀態，需求細分到具體的需求功能點，同時測試人員提交的缺陷應該對應到具體的需求功能點上面。一個需求開發完成后，需求本身也到待驗證狀態，但是一個待驗證的需求是否能夠關閉則必須是改需求下面所有的bug都解決完成后才能夠關閉。
需求和缺陷狀態的變化：開發人員首先是將需求或缺陷完成，并在本機進行自測通過，然后將代碼check in到配置管理庫。同時手工將需求或缺陷狀態處理到待部署狀態。在流水線啟動后，如果整個構建打包和部署成功，則在成功完成應用部署后，將待部署狀態的需求或bug轉到待驗證狀態。在部署完成后測試人員可以看到待驗證的bug或需求，那么他進入當前的測試環境一定是最新的可以進行缺陷驗證的環境。
應用部署和環境遷移：如何理清這兩者的關系，包括在流水線節點設計的時候是同種類型的一個節點還是不同的兩個節點？對于應用來說是直接將編譯打包后的鏡像執行進行部署，前面有編譯構建操作；而對于環境遷移來說則是直接從制品庫里面使用已有鏡像進行環境部署。
流水線模板和流水線實例應該是兩個不同的概念，一個流水線模板每次運行都會產生一個實例，而每次實例都會形成一次構建版本號。即每次打包后形成的鏡像入庫也會附帶上這么一個流水線實例號。那么我們的應用部署操作本身就簡單的，對于應用部署活動節點編排在流水線上面，作用是進行應用部署，但是本質是從制品庫拿到對應鏡像去部署？如何拿到對應鏡像，基于流水線實例號就可以很好的進行對接上。
從SIT到UAT環境：在環境遷移中，我們設置兩個環境，一個SIT環境供內部測試人員測試，一個UAT環境供客戶方進行UAT測試，那么在SIT測試完成后可以將SIT環境的鏡像包遷移到UAT環境進行部署。那么并不是每一次流水線作業都涉及到環境遷移操作，而實際上需要測試人員去判斷當前的測試版本是否需要遷移到UAT環境去供用戶測試。同時測試人員在當前測試問題全部修復并關閉后可以對當前版本打配置基線操作。其次，對于用戶測試提交的問題一般并不會在我們自己的缺陷管理系統進行Bug記錄，因此用戶反饋問題給測試人員，測試人員幫忙錄入到缺陷管理系統，同時缺陷修改完成后測試先要驗證沒有問題，再通知用戶進行驗證，只有用戶驗證通過后缺陷才能夠最終關閉。
遠行科技
遠行云商
