導入 version control 的考量(續)

本篇有點算是抱怨文。

1. Thinking about Server Networking
不管是集中式還是分散式的版本控管軟體，當超過一定數量的人同時開發時，都免不了要架設集中式的 Server。
Server 的架設有兩點需平衡：便利性、安全性。
大部分的公司為了安全會將 Server 架設在內部網路，外部則可能須透過 VPN 或甚至完全無法存取。
由於很多人長期都在不同的地點工作，而且可能得同時處理很多案子，在這種考量下，我個人是傾向讓 Servre 能對外，不管在哪裡，都隨時能存取到最新資料。
聽說某年敝公司突然在年中大會推廣甚麼 GDD (Geographically Distributed Development)，重點是當時官方版本控管工具 Clear Case 的架設根本完全無法符合 GDD 的需求，公司的 VPN 又慢到吐血，然後就算 VPN 進到公司網路後，還得遠端連到有加入 domain 的機器，才能使用 CC......這到底是甚麼決策......果然最後都完全失去意義。

2. Thinking about Authentication
授權與認證的方式。如果有"真的" single sign on 的機制，最好是能夠整合。退而求其次則是盡量和專案進行中會使用的系統整合，例如 project management system、bug tracking system 等等(如果有的話......)。
如果都沒有，我會建議自己架設 LDAP Server，畢竟大部分的系統都可以透過 LDAP 進行認證。
對於那種花錢導入了工具、又不是很好用、又得記好幾組帳號密碼的，真的有點......

3. Thinking about Directory Structure
在檔案總管時代，就存在資料要怎麼放的問題。導入了版本控管系統後，這個問題依然存在。敝公司之前有 CMMI Level 3 的規範，所以在"假設"未來這些資料都會放到 CC 裡的原則下，就採用公司定好的目錄結構。

4. What kind of data should be controlled?
其實有很多檔案是不用受控管的，例如自己電腦上環境的設定、每次開啟 IDE 會動態改變的檔案，可能在專案的進行中，得持續地調整。
之前遇到比較大的爭議是：編譯後的執行檔需不需要進版本控管？
我個人是傾向不要，但前提是編譯程序、開發環境建置程序要受到控管。如此只要拿到正確版本的原始碼+編譯程序，在相同的開發環境下，不管編譯幾次，執行檔都會相同。

5. What is the timing of committing data?
這其實是一個有點嚴重的問題。
在集中式版本控管系統中，只要沒有 commit/checkin 到 server，資料就不受控管。
如果把開發到一半的程式 commit 到 server 一定會對別人造成影響；但如果拖了很長的時間都沒有 commit，這段時間內的修改都不受控管，也可能會發生問題。
所以一般常見的做法會是 UT 過後才 commit、每天告一段落時 commit(前提是不會導致別人 compile 有問題)。

這時候，分散式版本控管系統的好處就顯現出來了。(不著墨)

6. Backup policy
這點主要是和"用檔案總管"來比較。用檔案總管要進行備份時，若檔案數量很多，備份的速度會非常慢，光是複製一份可能就要很多時間，如果要區別每次異動，用檔案總管更是困難。
版本控管系統大多都有所謂的 repository，使用的是 db 的形式在紀錄版本間差異，repository 的檔案數會遠小於與實際受控管的檔案數量，整體的檔案大小也會比原本的資料小(即便是已經紀錄了好幾版的異動)，所以備份起來非常快速。

7. Thinking about Libraries Distribution
Java 的程式中，常常會使用到大量的 3rd party libraries(我真的不知道怎麼翻比較好 = =)，如果這些 libraries 也進版本控管，有時候檔案數量及大小可能相當驚人。
因此可能會使用 maven、gradle 之類的 library management tool，這類工具會在需要的時候從網路上下載指定版本的 libraries，如此便只需要將這些工具的設定檔放入版本控管系統中即可，只要透過相同的設定檔、相同的操作，便能取得相同的 libraries。

8. Thinking about Coding Standard/Style
有人喜歡用 Tab 排版、有人喜歡縮排 2 個空白、有人喜歡縮排 4 個空白、每個人程式碼喜歡斷行的地方不同、甚至換行符號不同等等諸如此類雞毛蒜皮的小地方，都會產生資料的差異，可能造成無謂的 commit/checkin。所以一開始就需要規範好 coding standard/style，避免這種問題發生。大部分的 IDE 都提供 source code 排版設定的匯出匯入、或是 auto formating 的功能，有助於減少這類情況發生。

9. Will distributed revision control be next?
基本上我覺得如果工程師的工作性質是常常會到處跑、常常得同時間處理多個專案，分散式的版本控管系統絕對比集中式的好用。只是分散式在操作上相對複雜不少。
說實話，最近用了 git 後，其實就很不想再用回 svn。
但是要推行到組織中的話，以過去的經驗來看，集中式都不好推了，更遑論相對複雜的分散式......