團隊做業Week14——源代碼管理

　　0. 在吹牛以前，先回答這個問題： 若是你的團隊來了一個新隊員，有一臺全新的機器， 大家是否有一個文檔，只要設置了相應的權限，她就能夠根據文檔，從頭開始搭建環境，併成功地把最新、最穩定版本的軟件編譯出來，並運行必要的單元測試？ （在這過程當中，不須要和老隊員作任何交流）

---

　　答：是。

　　這個問題早在Alpha階段初期就困擾了咱們團隊。咱們爬蟲的核心基本就在兩個方面——爬取和存儲。爬取動做是在代碼實現之中的，編譯程序不會遇到什麼大的問題。而存儲涉及到了咱們項目的核心之一——數據庫。因爲軟工和數據庫是在同一學期開設的課程，大多同窗在開始Alpha的時候數據庫知識匱乏，而咱們的程序卻必需要鏈接數據庫纔可以正常運行。當時我本身再摸索成功鏈接上數據庫時就把鏈接數據庫的幾個常見的問題寫成博客發表了出來。新成員若是可以閱讀咱們這一博客，成功鏈接上數據庫，那麼編譯過程和單元測試問題不大。

　　這是咱們早在11月4號就寫好的博客，在Beta階段中對兩位新成員運行程序也提供了幫助。（當時新成員仍是與咱們進行了直接的交流來更輕易的執行程序。可是相信就算不與咱們進行任何交流，多花費些時間按照博客的操做鏈接上數據庫，也是可以編譯程序來進行測試的。）

　　http://www.cnblogs.com/cnmxfd/p/4935890.html

 

1. 你的團隊的源代碼控制在哪裏？用的是什麼系統？如何處理文件的鎖定問題？

   場景：  程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候， 程序員小飛也要改其中一個文件，快速修復一個問題。怎麼辦？

    一個代碼文件被簽出 (check out) 以後，另外一個團隊成員能夠簽出這個文件，並修改，而後簽入麼？

   有幾種設計，各有什麼優缺點？

   例如，簽出文件後，此文件就加鎖，別人沒法簽出；  或者， 全部人均可以自由簽出文件

---

　　答：咱們使用的是TFS的源代碼資源管理器進行源代碼的管理。

　　其實這一問題在咱們Alpha階段進行代碼簽入時就有出現：

　　

　　從圖中能夠看出我在11.9號中午的時候反覆進行代碼簽入，這就是由於在Alpha階段初期咱們對源代碼管理的疏忽而產生的問題。幾名成員同時對某一個變動集工做多日而久久不進行代碼的簽入，致使最後簽入的時候新舊代碼循環覆蓋。

　　因此在Beta階段剛開始，我就再三更DEV們聲明：當天若是有代碼實現，就算實現了一半，也能夠用註釋的方法將之進行代碼簽入，天天編寫代碼以前獲取最新版本的代碼。然而仍是會出現這樣的問題：由於成員們大多編碼時間都集中在晚上9~11點之間，因此就算進行了這樣的行爲規範，仍是難以免在同一時間共同操做同一變動集的問題。在出現了這種狀況以後，咱們利用TFS源代碼資源管理器自帶的鎖，避免了這樣一種狀況的出現：

　　

　　編碼人員在肯定了要修改哪幾個.java文件以後，就在TFS源代碼管理器上對其鎖定，此時其餘編碼人員的簽出動做就會被拒絕。等待該.java文件獲得修改以後，爲其解鎖，其餘人員就可以簽出該文件的最新版本了。（與多線程的鎖的控制原理簡直如出一轍，其實就是爲了防止兩個編碼人員在同一時間對同一文件進行操做形成了最終該文件內容的不肯定性）

 

 

2. 如何看到這個文件和以前版本的差別？ 如何看到代碼修改和工做項 （work item），缺陷修復 （bug fix) 的關係。

   場景： 程序員果凍看到某個文件被修改了，他怎麼看到這個文件在最近的修改究竟改了哪些地方？ 

   場景： 程序員果凍看到某個文件在最新版本被改動了100 多行， 那麼和這100多行對應的其餘修改在什麼文件中呢？ 這個修改是爲了解決哪些問題而做的呢？ 那些問題有工做項 （work item，issue），或者bug 來跟蹤麼？

---

　　答：這一功能在TFS的源代碼資源管理器也能進行操做。當時Alpha階段因爲初期代碼管理紊亂的問題也正是經過變動集的反覆比較而最終肯定下最新的變動集的。

　　

 

　　如圖咱們能夠將本地代碼與某一指定變動集進行比較，也能夠將歷史中的兩個變動集進行比較。比較結果將會返回有差別的文件，點開差別的文件咱們就可以看到具體的代碼不一樣：新添了綠色陰影部分的代碼。

　　

 

 

 

3. 若是某個文件在你簽出以後已經被別人修改，而且簽入了，那麼你在簽入你的修改的時候， 如何合併不一樣的修改（merge)? 你用了什麼工具來幫助你？

---

　　答：在Alpha階段時咱們趕上這種狀況只能經過比較，而後各自找出最新的代碼塊新添入本身的.java文件中再進行簽入。現在咱們能夠經過TFS上的分支與合併有效解決這一問題，因爲鎖的問題會影響DEV們的編碼時間，因此在對某一文件進行簽出修改以前，咱們能夠爲他創建一個新的分支，在編碼以後把分支合併回去。這樣可以解決一個文件遭到同時修改的衝突，也可進行比較進行選擇。

　　

 

　　合併以後再將主分支進行簽入。

　　

 

4. 你有20個文件都是關於同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？

    場景： 程序員果凍要簽入 20 個文件，他一個一個地簽入， 在簽入完5 個 .h 文件以後， 他發現一些 .cpp 文件和最新的版本有衝突，他正在花時間琢磨如何合併... 這時候， 程序員小飛從客戶端同步了全部最新代碼， 開始編譯， 可是編譯不成功 - 由於有不一樣步的 .h 文件和 .cpp 文件！  這時候， 別的程序員也來抱怨一樣的問題，果凍應該怎麼辦？

---

　　答：在這兩個階段咱們都沒有碰到過這樣的狀況，由於沒有同一時間簽入如此多的修改而且剛好碰到這樣悲劇的小飛。但我想也許以下幾個方法能夠進行嘗試：

　　1.直接對工程文件進行整個的簽入掛起的更改，這樣TFS會直接把有更改的全部文件進行簽入（尚不知道這樣作是否具備原子性）。

　　

 

　　2.在修改以前爲將要修改的文件都上鎖，防止其餘DEV在簽入的時候進行簽出操做。

 

 

5. 你的PC 上有關於三個功能的修改，可是都沒有完成，有不少文件處於半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，保證在乾淨的環境中修改這個 bug, 併成功地簽入你的修改 --- changelist management。

---

　　答：一樣沒有遇到過。可是分支應該是解決這一問題的有效方法。在對文件修改以前創建分支並在這個分支上進行功能的修改，若是遇到BUG，則在主分支上再創建一個新的分支，最後當這兩個分支都完成以後把它們合併到主分支當中去。

 

 

6. 如何給你的源代碼創建分支？

    場景：大家須要作一個演示，因此在演示版本的分支中對各處的代碼作了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 大家怎麼作到的？ 在演示以後，演示版本的有些修改應該合併到主分支中，有些則不用，大家是怎麼作到的？

    場景： 大家的軟件發佈了，有不少用戶，一天，一個用戶報告了一個問題，可是他們是用某個老版本，並且沒有條件更新到最新版本。 這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？

---

　　答：

　　經過TFS源代碼資源管理器能夠爲某一.java文件創建新的分支：

　　

　　場景一：演示版本的代碼是實如今分支當中的，因此咱們能夠在演示時用分支的代碼進行編譯，主分支仍舊留在服務器之中，若是某些分支的修改是主分支所須要的，則把相應的分支合併到主分支便可。

　　場景二：首先咱們會分析這一問題的體驗影響程度，而且對這一老版本的用戶量作一個估計的考量（報告此問題的人次也可反映），並查看新版本是否也存在這一問題。若是一切指標指向這一BUG的影響不容忽視，咱們能夠經過變動集歷史找到老版本，在相應的變動集上進行回滾，就可以重現當時的代碼。

　　

 

 

 

7. 一個源文件，如何知道它的每一行都是何時簽入的，爲了什麼目的簽入的 （解決了哪一個任務，或者哪一個bug）？

   場景： 一個重要的軟件突然出現崩潰的狀況，  程序員果凍通過各類debug手段，發現問題是在某一個文件中有一行代碼彷佛顯然出了問題，可是這個模塊被不少其餘模塊調用，這行代碼是何時，爲了什麼目的，通過誰簽入的呢？若是貿然修改，會不會致使其餘問題呢？ 怎麼辦？

---

　　答：在TFS源代碼管理器中，可選中改行查看歷史記錄：

　　

　　結果會顯示改行的修改記錄，經過後面的註釋能夠知道該次簽入的說明。

　　

 

　　場景回答：因爲歷史查看也會顯示出修改人員，能夠向該次修改的DEV進行更詳細的詢問。

 

 

 

8. 如何給一個系統的全部源文件都打上標籤，這樣別人能夠同步全部有這個標籤的文件版本？

   代碼天天都在變， 有時質量變好，有時變差，咱們須要一個 Last Known Good （最後穩定的好版本） 版本， 這樣新員工就能夠同步這個版本， 咱們若是須要發佈，也是從這個版本開始。那麼如何標記這個 Last Known Good 版本呢？ 

---

　　答：咱們兩個版本的源代碼管理都沒有用到標籤。多是應該項目規模還比較小，用標籤的收益不大。標籤其實就是爲整個項目或者某一個.java文件制定一個索引，在版本的推移中，如若發現新版本的各方面均不如以前的版本，能夠經過標籤查到到以前的版本或者某一文件。

　　從標籤的試用上來看，標籤在大型項目中會十分靈活。可以快速定位到某一個變動集並對其進行操做。

　　

 

　　標籤test的查找結果：

　　

 

 

9. 你的項目的源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？ 修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？

    在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？

    在程序員提交簽入以後，服務器上是否有自動測試程序， 完成編譯，測試，若是成功，就簽入，不然，就取消簽入？

    團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

　　答：測試目前的確是咱們團隊一個一個短板，場景所提到的自動測試程序咱們幾乎沒有。現在Beta的開發階段已通過去，也僅是對成員作出測試數據記錄以及測試日誌的上傳，測試強度依然欠缺。從如今到項目展現的這段時間，咱們會尤爲重視測試。如若時間條件容許，也會編一個自動測試程序進行各個變動集的編譯測試。