<h2>配置管理</h2>
<strong>配置管理</strong>是指以漢人過程，通過該過程，所有與項目相關的產物，以及它們之間的關系都被唯一定義、修改、存儲和檢索。
<h4>使用版本控制</h4>
<strong>學到：</strong>
<strong>版本控制系統</strong>顧名思義就是管理開發中項目內容的系統，接觸最多的是Git，使用它的好處是如果發現項目出錯很容易滾回到上一個版本然后找到出錯的地方也可以根據提交的歷史記錄找到是誰提交的哪部分代碼出現了問題。
<strong>對所有內容進行版本控制</strong>
<strong>頻繁提交代碼到主干</strong>
<strong>使用有意義明顯的提交注釋</strong>
<strong>想到：</strong>
所以應該對所有內容進行版本控制，讓整個項目透明化。
我們最容易忽略的事情就是對文檔的記錄，尤其是在使用版本控制的時候，我們很少會去提交文檔，但是有的時候開發人員并不是在一起的，所以對使用的協議代碼規范，或者測試用例各種并不能及時交流，可能會出現在最后發布的時間發現彼此依照的文檔不同，導致整個項目的運行出錯。
如果我們拿到的任務卡是一個比較大的模塊，很多時候為了不必要的麻煩，我們會在徹底完成這個模塊后再去提交，但是這樣真的省去麻煩了么？當然是不一定的，在最后提交的時候，可能會和其他人提交的代碼沖突，可能在別人引用的時候出錯，可能會出現很多難以預料的問題。也有人喜歡新建單獨的分支，當覺得自己代碼 ok 的時候才去合并，同樣的，這樣的方法也是容易出錯的。我們提倡，頻繁的提交代碼，保證你的代碼隨時不與項目里的其他人代碼沖突。
提到注釋，大家總覺得這不是那么重要，提交代碼注釋的時候也可能是“first commit”、“change bug”、“add page”等等這些模糊的沒有多大意義的注釋，但是如果項目出現了的bug是前面別的開發人員提交的代碼導致出現的，那要怎么去處理，僅僅根據“change bug”你很難得出結論，他為什么要這樣寫，這個時候就深刻的意識到了注釋的重要性。
<h4>依賴管理</h4>
<strong>學到：</strong>
現在的項目大多應該是在前人的肩膀上去實現的，導入一些依賴直接引用，但是這些外部依賴庫文件要不要放入版本控制庫中呢？每一次的pull與push都挺費時的，業界對這個問題一直都是存在爭議的，具體怎么做還是根據具體項目要求自己衡量吧。
<h4>軟件配置管理</h4>
<strong>學到：</strong>
<strong>配置信息與產品代碼及其數據共同組成了應用程序。</strong>那么該如何管理系統配置？建議用對待代碼的方式去對待系統配置，合理的去管理和測試。
<strong>配置的分類，</strong>構建、部署、測試、發布每一步都可以進行配置信息的設置。
<strong>應用程序的配置管理</strong>
如何描述配置信息？
通常配置信息以鍵值對的形式來表示，有時使用系統配置類型來有層次地組織這些配置項，也可以將配置信息以XML文件的形式來保存可以對其復雜性起到較好的限制效果。
部署腳本如何存取這些配置信息？
數據庫、版本控制庫、文件目錄或注冊表等。但是對主要的信息的存取需要施加限制。
在環境、應用程序各版本之間，每個配置信息有什么不同？
每個配置都是一個元組，但是取值取決于應用程序、應用程序的版本、版本運行環境三方面。
<strong>想到：</strong>
以前總覺得配置信息沒有那么重要，主要是大家用的環境工具都是相同的，但是最近課設，和同學一起做項目，才真正感覺到了配置不同帶來的麻煩，她寫的代碼在我這里根本不能運行，我寫的代碼她導入的方式不對也是無法合并的，看到這里意識到了配置信息的重要性。
<h4>環境管理</h4>
<strong>學到：</strong>
環境管理的關鍵在于通過一個全自動過程來創建環境，使創建全新的環境總是要比修復已受損的舊環境容易得多。
高效配置管理策略的兩個基本原則：1.將二進制文件于配置信息分離；2.將所有的配置信息保存到一處。
<strong>變更過程管理</strong>應該嚴格控制生產環境，未經組織內部正式的變更管理過程，任何人不得對其進行修改。
<strong>想到：</strong>
環境重現也是很有必要得，如果我們修改的是別人寫的代碼，遇到問題可以想一下他當時的運行環境，明白他這樣寫的意義。
環境的也是需要自動化過程的，這樣就會把變更的風險降到最低。
環境的破壞可能來自很小的變化，所以要記錄每一次變更。
