版本控制：
應該對所有的內容（包括源代碼，構建腳本，測試，文檔，需求，數據庫腳本，代碼庫以及配置文件，開發，測試，運維的工具及所有環境及其配置等）進行版本控制，包括項目開發得所有產出而不僅僅是源代碼，我們組課設因為沒有將配置信息加入版本控制，導致大家的配置環境不同，整個程序不能完整的移植，只能根據交換部分代碼。
頻繁提交：
頻繁提交會使得合并工作變得方便簡單，大家可以及時的看到你的代碼，并判斷你的提交是否破壞了應用程序，如果發現錯誤可以及時回復到你提交前的狀態，確保應用程序完好，而且你也以及及時修改錯誤（尤其是方向性的錯誤）防止這個錯誤影響后續的開發，可以提高開發效率。
不支持分支
創建分支不利于持續集成，在開發中所有人應該在主分支上頻繁提交代碼，為了確保提交的代碼的正確性，我們需要在提交之前進行測試
提交注釋很重要
有時候我在GitHub上提交代碼時提交注釋不知道怎么寫就用 update 代替，導致查看時不知道上次提交修改了什么東西。所以每一次的修改或者增加都要盡可能詳細的描述所做的工作。
需要注意的：
- 配置信息的版本要與相應的軟件相匹配
- 將源代碼與配置信息存放于單獨的代碼庫中，有利于信息的安全性
- 構建流水線之間的依賴應該是二進制文件依賴，執行效率高，但是會給問題追蹤帶來困難，解決這一問題需要一個好的持續集成的服務產品
- 配置信息與代碼同樣重要
- 任何改變程序的行為都是編程，即使是修改一行配置信息
獲取配置信息
- 使用文件系統可以跨平臺，獲得各種語言支持
- 從某個中心倉庫獲取配置信息
冒煙測試
“冒煙測試”這一術語描述的是在將代碼更改嵌入到產品的源樹中之前對這些更改進行驗證的過程。來源于硬件測試， 在檢查了代碼后，冒煙測試是確定和修復軟件缺陷的最經濟有效的方法。 冒煙測試設計用于確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。
高效配置管理策略的基本原則
- 將二進制文件與配置信息分離
- 將所有的配置信息保存在一處
小結
配置信息很重要，而且配置信息出錯不易于查找錯誤原因，修改風險大，所以開發團隊需要以謹慎的態度對待，對于課內實驗環境的配置，我們可以采用寫博客的方式將配置過程記錄下來，方便大家查閱，或者將像 Java 的 jar 包之類的第三方庫文件上傳到 GitHub 上，一個團隊盡量使用相同版本的庫文件。
生產環境和測試環境要受到同等的重視，這兩個環境要盡可能一致，這樣可以減少部署時出現的問題。
疑問
- 對于配置信息的表示形式（鍵值對）不理解
- 為什么將配置信息以XML文件形式儲存可以對復雜性起到限制效果？
- 系統配置的測試方法有哪些？
- 配置管理與持續集成，部署流水線的聯系是什么？
