誤打誤撞進入
配置管理這個行業約2年，還是有很多東西不清楚。網上倒是有很多軟件類配置管理的知識可以獲取、
學習。但總覺得使不上勁，好像有一層云霧籠罩著，摸不清方向。曾經一度想加入
測試或研發團隊，通過了解研發流程，以便提出合適的配置流程和方案。無奈還是隔靴搔癢地在綜合辦里坐著，只能通過和研發人員溝通、看博客混論壇來了解這個領域的狀態。
今天又仔細看了構建管理的相關定義，突然有了一些豁然開朗的感覺。寫出來和各位同仁探討，不足之處，還望不吝賜教。
配置管理是縮寫是CM (Configuration Management)，而業界很多人卻稱自己是SCM（Software Configuration Mangement, 軟件配置管理）。但是卻沒有與之相對應的HCM (Hardware Configauration Management）。如果在
谷歌或
百度搜索配置管理，順藤摸瓜會發現與之關聯密切的一些術語，比如：構建，編譯，打包，發布，部署等等。
軟件配置管理的體系和工具都已經很成熟（但這不表示我們這個國家的多數軟件公司已經在用它們），而硬件方面的就較少。而這套成熟的軟件系統又顯然不太適用于芯片類和系統類的產品。
造成這種配置管理軟件強而硬件弱的現象，筆者考慮主要是下面的原因：
1）配置管理對工具的要求較高。由于軟件行業在這方面有著天然的優勢，對應的解決方案就比較多（實現相對容易）。例如
IBM和MS就不乏這樣針對軟件研發過程的產品。
2）軟件公司的開發模型大致相近（或分為幾類）。這類產品將標準的軟件研發過程包含在內，很快在其它軟件公司中得到應用和推廣。
而芯片類和系統類的工程師在開發類似定制軟件的技術實力和動力方面都不足（不會像軟件公司那樣做好了還可以作為產品銷售）。因此，芯片行業缺少通用的配置流程和可選工具就不奇怪了。
目前，我們能做的就是按照公司的研發流程和cmmi等標準的要求，參考當前軟件配置管理的優秀實踐，定制地開發復合公司需求的配置管理方案。解決代碼管理，編譯，測試，發布等問題。
芯片產品包括：芯片設計（最終形成芯片的硬件部分）和固件設計（boot、cos、驅動、下載工具等）。
對于芯片硬件的設計，其研發流程很長。與軟件類的差別就比較大了，比如加入了仿真、模擬、版圖等環節。
對于芯片固件的設計，可以參考普通軟件類產品的配置管理流程。
當然，雖然可以借鑒現成的流程，但工具卻不一定能套用。因為芯片固件采用的是嵌入式開發（例如用C語言編寫）。
軟件配置管理的思路有很多值得借鑒之處——比如，構建自動化、測試自動化、自動打包、自動編譯。這些工具或環境，其實就是將研發流程中可以讓機器做（而且可能比人做更高效、準確）的部分單獨拿出來，盡可能地讓機器（編譯服務器、構建服務器）實現。 包括版本控制、質量控制（自動測試）、編譯。
當然，以上的分析也只是為芯片類的配置管理找到了一個可能的方向，剩下就是進一步的確定需求、制定解決方案、實施、試點、推廣。
如果有在
華為海思或其它芯片類公司
工作的配管，看到這篇
文章，也可以與我交流。 yanyuzuo@qq.com
和做配管的同行交流多了，似乎有一種觀點，配置管理和
項目管理、
質量管理一樣，在不同的公司有很大的差異性。
但是，拿發展成熟的制造業來說，ERP系統幾乎已經成為標配，各個公司的ERP系統也許會有細節不同的地方，但其功能卻相差無幾。
配置管理也是一樣，我們可能需要定制，但是一定有一套基礎的系統（base），是放之四海而皆準的。