持續交付(第二章)—配置管理

在上一章中,作者列舉了一些在軟件開發中常見的問題,比如,手動部署項目,代碼沒有測試,團隊協作沒有采用版本控制系統等等,同時也告誡了我們一些避免的方法,在上述的一些問題中,我都不幸中彈了,也發現了自己的一些可以改進問題,領悟到一個道理:軟件開發絕不僅僅是寫代碼而已。

在這一章作者向我們介紹了如何管理你的配置,剛看這一章時,我有點懷疑我之前理解的配置定義是正確的么?最后發現只是理解的有點片面了。

持續集成

配置管理定義

配置管理是一個過程,通過該過程,所有與項目相關的產物,以及它們之間的關系都被唯一定義,修改,存儲和檢索。

配置管理通常與版本控制作為同義詞出現,版本控制系統是配置管理的實現工具。配置管理所需要管理的內容不僅僅是項目源代碼,有關項目的所有文件都應該被包含,比如,測試代碼,數據庫腳本,構建和部署腳本,文檔,庫文件和應用軟件配置文件等等

版本控制

版本控制系統是保存文件多個版本的一種機制。當修改某個文件后,你仍舊可以訪問該文件之前的任意一個版本,極大促進團隊的共同合作。

現在比較普遍常用的應該就是git了,使用版本控制系統的兩個主要目的是,保留每個文件的所有版本的歷史信息,使之易于查找,可以回到最近一次正確的版本中。提供基于元數據的訪問方式,使元數據與某個單個文件或集合相鏈接。

還有一個很重要的點,那就是真的真的要對項目所有內容進行版本控制,這樣一個極大的好處就是能夠隨時獲取軟件在生命周期中任意節點的文件狀態,這樣就可以選擇從開發環境至生產環境整個環節的任意時間點,并將系統恢復至那個時間點。

依賴管理

依賴管理一般就是管理項目中所使用的第三方庫,以及該項目需要用到的正由其他團隊開發的模塊或組件間的關系。

由于這些第三方依賴,一般來說都是二進制文件,且變更不頻繁,所以到底要不要納入版本控制系統中呢?我覺得可以不納入,就存在本地就好了,這樣也可以減少遠程版本控制庫的尺寸。

軟件配置管理

配置信息與產品代碼及其數據共同組成了應用程序。
一般來說我們會在軟件開發的任何時候都會進行軟件的配置,因為很難做到那種一勞永逸的軟件配置,并且這種配置也是很危險的。

將那些特定于測試環境或產生環境的實際配置信息存放在與源代碼分離的代碼庫中是十分必要的,因為這些信息肯定與代碼的更新頻率是不同的,但是我們要保證兩者具有相同的版本號

環境管理

沒有哪個應用程序是孤島,每個應用程序都依賴于硬件,軟件,基礎設施以及外部系統才能工作,我們把這些稱為軟件的環境。

上面所說的那些組成環境的元素,我們都應該納入版本管理系統,以及每次的變更都要有所描述并提交遠程,對每個修改都要進行測試,以確保它不會破壞在新版本的環境中運行的程序。

環境管理也是可以使用工具來實現的,這樣你就可以來聲明一些事情,定義一些權限。

總結

看完這一章,有解決之前遇到的問題,也有一些新的問題出現。

我的收獲

  • 重新了解了配置管理
  • 開發項目時的確應該將所有資料文件納入版本控制系統
  • 深刻了解到版本控制系統的必要性
  • 增量式開發就是小步提交
  • 多些注釋,注釋也是有基本的結構的

我的疑惑

  • 還是不能很好區分配置管理,版本控制,環境管理,軟件配置這幾個詞語。
  • 在這一章中,作者說要盡量避免為了一個功能重新創建分支,和git flow工作流程就沖突了
  • 軟件配置到底應該在什么時候進行,構建?部署?測試還是發布,之前些項目好像都是一邊些項目一邊覺得缺少配置再添加
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容