1. 程式人生 > >【20181218】releasemanager之老本行:版本控制和環境管理

【20181218】releasemanager之老本行:版本控制和環境管理

繼續根據軟體業務價值流圖來學習總結,本篇我們接著上一次的需求管理&變更管理來關注與它們密切相關的版本控制。

版本控制可以說是我的老本行了,在華為的五年配置管理崗位都是圍繞著版本控制打轉,然而當時還沒有徹底理解版本控制的意義所在。如今將版本控制作為持續交付流水線的一部分來看待,反而能對其本質有更深一層的理解。

版本控制是變更管理的最佳拍檔和技術手段,它能夠控制和記錄目標物件的每一次變更資訊,確保變更過程可控和可追溯。常用的版本控制工具包括Git/SVN/Perforce等,各有自己的優缺點,比如Git適合管理原始碼,Perforce適合管理二進位制製成品。

執行版本控制需要秉持一個理念:將一切納入版本控制庫管理。這裡的一切不僅包含原始碼,同時還包含資料庫指令碼、構建指令碼、測試用例、測試指令碼、部署指令碼、相應工具集、配置檔案等所有與軟體程式質量相關聯的內容。

在將一切都納入版本控制庫管理後,即可以體現出版本控制的第一點意義:協作同源。版本控制可以使得所有團隊清晰地維護同一份源頭,避免出現資訊壁壘,提高協作效率。

版本控制通常與線上評審工具系統配合使用,例如git與gerrit,這體現出版本控制的第二點意義:變更可控。通過許可權配置方案與變更評審機制,可以確保每一次變更都經過所需要的稽核後才能生效。

版本控制的第三點意義,也是最重要的一點,即是:變更可溯。可溯分為兩部分:第一,版本控制工具可以記錄目標的每一次變更資訊,並使用一個唯一的全域性版本號來標識這次變更,那麼後端的構建、歸檔、測試、部署過程均可以記錄相應的全域性版本號資訊,以確保每一次的流水線產物都可以清晰對應到具體變更。第二,版本控制工具可以通過指令碼或鉤子使得目標的變更資訊中帶有對應的變更流程單號(例如Jira bug單號或需求編號),使得每一次具體變更都可以對應到相關需求或缺陷的變更流程。通過變更可溯,可以確保從前端的需求到最終部署的產物之間的聯絡是清晰可見的。

版本控制的第四點意義就是使得持續交付的自動化程度大大提升,包括與持續整合的配合、與二進位制庫的配合等。

說完版本控制,我們再著重說一下其中的配置檔案相關管理。軟體的配置檔案包括很多種,比如編譯的配置檔案、應用啟動的配置檔案、環境的配置檔案等。此處我們關注環境的配置檔案(包括生產環境、類生產環境、測試環境、開發環境等),即業界所說的“基礎設施”管理。

如今的基礎設施管理為了滿足軟體應用更頻繁更復雜的釋出場景,必須依靠更加規範的管理和更高程度的自動化,來實現快速的環境新建、伸縮和銷燬等。業界常說的“基礎設施即程式碼”即是這個目的,通過Puppet/Ansible等工具將環境的搭建轉換成描述性的語言(維護環境配置檔案),確保生產、類生產、測試甚至開發環境的搭建都經過充分的評審和測試並且實現自動化和視覺化。虛擬化技術和Docker容器技術更使得基礎設施的管理效率上了一個臺階,環境的擴容、伸縮和銷燬代價更小,能夠支撐的場景壓力也大大增加。

環境管理是持續交付不可或缺的一環,是實現持續部署進而持續交付的基礎。常用的工具包括Puppet/Ansible/Docker/K8s等,後面在總結持續部署時我們會再進行學習。