繼續根據軟件業務價值流圖來學習總結，本篇我們接着上一次的需求管理&變更管理來關注與它們密切相關的版本控制。
版本控制可以說是我的老本行了，在華爲的五年配置管理崗位都是圍繞着版本控制打轉，然而當時還沒有徹底理解版本控制的意義所在。如今將版本控制作爲持續交付流水線的一部分來看待，反而能對其本質有更深一層的理解。
版本控制是變更管理的最佳拍檔和技術手段，它能夠控制和記錄目標對象的每一次變更信息，確保變更過程可控和可追溯。常用的版本控制工具包括Git/SVN/Perforce等，各有自己的優缺點，比如Git適合管理源代碼，Perforce適合管理二進制製成品。
執行版本控制需要秉持一個理念：將一切納入版本控制庫管理。這裏的一切不僅包含源代碼，同時還包含數據庫腳本、構建腳本、測試用例、測試腳本、部署腳本、相應工具集、配置文件等所有與軟件程序質量相關聯的內容。
在將一切都納入版本控制庫管理後，即可以體現出版本控制的第一點意義：協作同源。版本控制可以使得所有團隊清晰地維護同一份源頭，避免出現信息壁壘，提高協作效率。
版本控制通常與在線評審工具系統配合使用，例如git與gerrit，這體現出版本控制的第二點意義：變更可控。通過權限配置方案與變更評審機制，可以確保每一次變更都經過所需要的審覈後才能生效。
版本控制的第三點意義，也是最重要的一點，即是：變更可溯。可溯分爲兩部分：第一，版本控制工具可以記錄目標的每一次變更信息，並使用一個唯一的全局版本號來標識這次變更，那麼後端的構建、歸檔、測試、部署過程均可以記錄相應的全局版本號信息，以確保每一次的流水線產物都可以清晰對應到具體變更。第二，版本控制工具可以通過腳本或鉤子使得目標的變更信息中帶有對應的變更流程單號（例如Jira bug單號或需求編號），使得每一次具體變更都可以對應到相關需求或缺陷的變更流程。通過變更可溯，可以確保從前端的需求到最終部署的產物之間的聯繫是清晰可見的。
版本控制的第四點意義就是使得持續交付的自動化程度大大提升，包括與持續集成的配合、與二進制庫的配合等。
說完版本控制，我們再着重說一下其中的配置文件相關管理。軟件的配置文件包括很多種，比如編譯的配置文件、應用啓動的配置文件、環境的配置文件等。此處我們關注環境的配置文件（包括生產環境、類生產環境、測試環境、開發環境等），即業界所說的“基礎設施”管理。
如今的基礎設施管理爲了滿足軟件應用更頻繁更復雜的發佈場景，必須依靠更加規範的管理和更高程度的自動化，來實現快速的環境新建、伸縮和銷燬等。業界常說的“基礎設施即代碼”即是這個目的，通過Puppet/Ansible等工具將環境的搭建轉換成描述性的語言（維護環境配置文件），確保生產、類生產、測試甚至開發環境的搭建都經過充分的評審和測試並且實現自動化和可視化。虛擬化技術和Docker容器技術更使得基礎設施的管理效率上了一個臺階，環境的擴容、伸縮和銷燬代價更小，能夠支撐的場景壓力也大大增加。
環境管理是持續交付不可或缺的一環，是實現持續部署進而持續交付的基礎。常用的工具包括Puppet/Ansible/Docker/K8s等，後面在總結持續部署時我們會再進行學習。