研發中版本管理的規範性

案例1：這階段公司內部在測試一個即將上線的產品，好幾回都遇到運行良好的服務在某個時間段後不能提供正確服務的狀況，因爲產品涉及到多個端，協做人員衆多，並且各端軟件的更替也較頻繁，在從內部排查問題的同時也在從外部着手肯定是否有人更改過某個程序，衆研發人員都說沒有更改過程序。可是隨着排查的深刻每每會發現是某我的搞混了本身發佈程序的版本。

案例2：團隊中有人在發佈動態庫或應用程序時採用日期來作版本號，在頻繁迭代的過程當中沒法使應用程序和源碼管理系統中版本對應起來，不利於定位問題。

案例3：使用源碼管理系統提交時爲了偷懶或者忽視，不標註或隨意填寫改動描述，在進行代碼回退時那個費勁。

---

版本管理的重要性在研發工做中不言而喻，缺少規範化在研發階段會嚴重影響開發效率，在測試階段也會形成不少無心識的錯誤，一旦到了發佈階段形成的損失會更大。記得在一次公司規範管理的會議上，老總曾提到過咱們的硬件產品因爲燒錄程序版本的問題給公司形成了很大的經濟和聲譽損失。因此如何規範化版本管理首先做爲研發人員和管理人員的咱們要在內心重視起來，進而採起措施去規範化版本。

源代碼和文檔管理：若是你的公司還沒用源碼管理工具進行源碼管理，你出頭的機會就來了，向他們推薦SVN和GIT吧（別笑，還真有不少公司沒有造成企業級的規範，我就逮到這麼一個機會），如今據我瞭解大部分商業公司仍是在使用SVN，剛纔案例3提到的提交改動描述的問題，SVN就沒有GIT作得好，SVN能夠提交空註釋，因而就發現衆多偷懶的程序員們一片片空白的註釋，這純粹是挖坑埋本身......。提到文檔，咱們程序員最最討厭了，但是又不得不寫，用一些富文本工具寫出的文檔沒法進行內容比對，建議使用markdown來維護文檔。

二進制程序的管理：對於二進制程序的版本規則，案例1給咱們的教訓是必須得有，案例2告訴咱們版本規則必需要可以表達必定的含義或者對應一致的源文件。最通用的形式一般是major.minor.build,在新版本推出時，應更新major、minor或是build的版號，決定於變動的大小。當有極大的更新時，會增長major的版號。而當有大更新，但不至於更新major時，會更新minor的版號。若更新比較小，例如只是除蟲（bug fixing），則會更新build的版號，這裏的build版本號一般能夠和源碼管理工具的revision版本號對應起來，這樣能夠把應用程序和相對應的代碼關聯起來，在進行bug查找或修正時是個很大的便利。

小知識:在windows下利用svn的TortoiseSVN工具subwcrev.exe能夠很容易獲取代碼的revision，配合vs的腳本工具能夠很容易的寫入程序中。    在linux環境下使用svnversion命令便可。