文章出處

問題來自于:現代軟件工程講義源代碼管理

0. 在吹牛之前,先回答這個問題: 如果你的團隊來了一個新隊員,有一臺全新的機器, 你們是否有一個文檔,只要設置了相應的權限,她就可以根據文檔,從頭開始搭建環境,并成功地把最新、最穩定版本的軟件編譯出來,并運行必要的單元測試? (在這過程中,不需要和老隊員做任何交流)

在團隊的資料庫的根目錄中,會有一個"開發快速上手指南.docx"這個文檔,這個文檔作為一個索引文檔,提供了資料庫里面所有相關文檔/工具的索引地址,格式可以多種多樣,我提供一種格式作為參考:

開發工具以及配置:

jdk: svn://xxx.xxxx.xxxx /jdk-7u80-windows-i586.zip

eclipse: svn://xxx.xxxx.xxxx /eclipse-jee-luna-SR1a-win32.zip

Tomcat: svn://xxx.xxxx.xxxx /apache-tomcat-7.0.55.zip

MySQL: svn://xxx.xxxx.xxxx /mysql-5.5.47-win32.zip

部署詳細步驟:

  1. 新建文件夾workspace
  2. 打開eclipse

    FileàSwitch WorkspaceàOther... àBrowse..., 選擇workspace這個目錄,點擊Ok,切換至新的工作空間

  3. 在新的工作空間里

    FileàImport... àSVNà從SVN檢出項目à創建新的資源庫位置àNext

àURL填:svn://xxx.xxxx.xxxx/xxx/xxxxàNextà選擇xxxxàFinish,即可導入項目。

  1. 配置Tomcat: xxx
  2. 修改配置文件:

    WEB-INF/目錄下的xxx.xml文件需要修改

  3. 啟動項目:

    例:項目加入Tomcat中,右鍵Tomcat,點擊Run

  4. 驗證項目是否啟動成功:

    訪問:http://localhost:8080/xxxx,主頁顯示,啟動成功。

 

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

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

    一個代碼文件被簽出 (check out) 之后,另一個團隊成員可以簽出這個文件,并修改,然后簽入么?

   有幾種設計,各有什么優缺點?

   例如,簽出文件后,此文件就加鎖,別人無法簽出;  或者, 所有人都可以自由簽出文件

 

針對這個場景,首先要劃分優先級,

如果小飛要修復的問題需要馬上立刻發布補丁,那么,小飛應該直接簽入修改的文件,發布完以后,果凍先備份自己寫好的文件,然后把小飛簽入的文件更新到本地,然后在本地將自己備份的文件和更新的文件進行merge即可。

簽出文件后,此文件就加鎖,別人無法簽出:

這種情況,可以保證每個人獲取的文件版本是最新的,也不會產生修改沖突。但是這種方式花費的時間相對要長一些,因為其他人要等簽出這個文件的人簽入完畢以后才能簽出下來進行修改。

所有人都可以自由簽出文件:

所有人都可以自由簽出文件,這種情況大家各自修改自己需要修改的模塊,但是到合并代碼的時候,需要人工Merge,這種方式風險會大一些,特別是同一個人修改一個文件涉及到相同函數的修改。

 

2. 如何看到這個文件和之前版本的差異? 如何看到代碼修改和工作項 (work item),缺陷修復 (bug fix) 的關系。

   場景:程序員果凍看到某個文件被修改了,他怎么看到這個文件在最近的修改究竟改了哪些地方? (例子

   場景:程序員果凍看到某個文件在最新版本被改動了100 多行, 那么和這100多行對應的其他修改在什么文件中呢? 這個修改是為了解決哪些問題而作的呢? 那些問題有工作項 (work item,issue),或者bug 來跟蹤么?

對于場景1的情況:

很多開發工具都自帶有show history的功能,對于文件的提交歷史以及提交修改可以查看到,以Android Studio為例:

 

此外,Github提供這樣一種方式來查看最近修改:

查看master分支最近7天內的差別:

https://github.com/mybatis/mybatis-3/compare/master@{7.day.ago}...master

查看與指定日期之間的差別,如下,查看最新版與2015年9月27號這個版本的差別:

https://github.com/mybatis/mybatis-3/compare/master@{2015-09-27}...master

 

對于場景2的情況:

我們曾經用過比較原始的方式:

基本是通過查看提交時候的comment來確定這次提交的修改原因是什么。Bug和功能列表通常在另外一個系統記錄,比如:Excel,在Excel里面對Bug和功能進行標記(已完成,未完成,進行中),一般開會的時候大家對近期修復的Bug和功能按照這個Excel表的內容一起來過一遍。

對于和這個100多行的修改一起簽入的其他修改,在Eclipse+SVN下可以查看相關修改的文件以及修改原因:

在某個文件上點擊右鍵:Team->顯示資源歷史紀錄:

Github上:

可以自動關聯Bug/ issue和每次簽入的修改之間的關系

用戶可以提交Issue,并把Issue標記為bug,開發人員提交代碼的時候,加上以下描述信息,對應的Issue就會被Close

fix #+Issue編號

如:fix #1 對應編號為1的Issue被關閉。

 

3. 如果某個文件在你簽出之后已經被別人修改,并且簽入了,那么你在簽入你的修改的時候, 如何合并不同的修改(merge)? 你用了什么工具來幫助你?

這種情況我一般的處理方式是備份本地自己開發的一份代碼,先把別人簽入的代碼更新到本地,然后在本地手動合并修改,用的工具是Beyond Compare。 

 

4. 你有20個文件都是關于同一個功能的修改,你要如何保證這些文件都同時簽入成功(修改的原子性),或者同時簽入不成功?

    場景: 程序員果凍要簽入 20 個文件,他一個一個地簽入, 在簽入完5 個 .h 文件之后, 他發現一些 .cpp 文件和最新的版本有沖突,他正在花時間琢磨如何合并... 這時候, 程序員小飛從客戶端同步了所有最新代碼, 開始編譯, 但是編譯不成功 - 因為有不同步的 .h 文件和 .cpp 文件!  這時候, 別的程序員也來抱怨同樣的問題,果凍應該怎么辦?

在簽入之前,一定要先對比處理有沖突的文件!

Eclipse+Subsversion有一個與資源庫同步的功能,這個功能可以顯示有沖突的文件(用紅色標注),在簽入的時候,先把沖突文件更新下來,與本地自己要簽入的文件進行一輪merge,參考第三題的方式,然后再把20個文件一起簽入即可。 

 

5. 你的PC 上有關于三個功能的修改, 但是都沒有完成,有很多文件處于半完工的狀態,這時你要緊急修改一個新的 bug,如何把本地修改放一邊,保證在干凈的環境中修改這個 bug, 并成功地簽入你的修改 --- changelist management

先備份本地修改的整個工程,然后把工程還原成(Revert)成基線版本(參考第九問),然后進行修改bug并簽入,最后通過Beyond Compare工具來對比本地備份的版本和最新的版本,并merge。

 

6. 規范操作和自動化

    你的團隊規定開發者簽入的時候要做這些事情:

    - 運行單元測試,相關的代碼質量測試

    - 代碼復審 (要有別的員工的名字)

    - 和這次簽入相關的issue 編號, 任務/task, 缺陷/bug 編號,等等, 以備查詢。

    請問你的團隊有這樣的自動化工具讓開發者方便地一次性填入所有信息然后提交么?  (高級功能, 代碼提交之后, 相關bug 的狀態會改動為  "fixed", 并且有鏈接指向這次簽入。)

例子

 

完善中….

 

   

7. 如何給你的源代碼建立分支

    場景:你們需要做一個演示,所以在演示版本的分支中對各處的代碼做了一個臨時的修改, 同時,主要的分支還保持原來的計劃開發。 你們怎么做到的? 在演示之后,演示版本的有些修改應該合并到主分支中,有些則不用,你們是怎么做到的?

    場景: 你們的軟件發布了,有很多用戶,一天,一個用戶報告了一個問題,但是他們是用某個老版本,而且沒有條件更新到最新版本。 這時候,你如何在本地構建一個老版本的軟件,并試圖重現那個問題?

 對于場景1:

以Github為例:

  1. 打分支
  2. 有條件地合并分支和主分支

對于場景2:

  1. 新建一個分支
  2. 在這個分支上,回滾到用戶所用的版本

在Github中,可以通過git log命令來查看歷史提交記錄

通過:

 

8. 一個源文件,如何知道它的每一行都是什么時候簽入的,為了什么目的簽入的 (解決了哪個任務,或者哪個bug)?

   場景: 一個重要的軟件歷經幾年,幾個團隊的開發和維護,忽然出現在某個條件下崩潰的事故, 程序員果凍經過各種debug手段,發現問題是在某一個文件中有一行代碼似乎顯然出了問題, 但是這個模塊被很多其他模塊調用,  這行代碼是什么時候,為了什么目的,經過誰簽入的呢?  如果貿然修改, 會不會導致其他問題呢?  怎么辦?

以Github為例:

執行git blame命令,即可顯示每一行都是什么時候簽入的,為了什么目的簽入的,簽入人是誰

或者在Github頁面

 

9. 如何給一個系統的所有源文件都打上標簽,這樣別人可以同步所有有這個標簽的文件版本?

   代碼每天都在變, 有時質量變好,有時變差,我們需要一個 Last Known Good (最后穩定的好版本) 版本, 這樣新員工就可以同步這個版本, 我們如果需要發布,也是從這個版本開始。  那么如何標記這個 Last Known Good 版本呢? 

 Last Known Good (最后穩定的好版本) 版本可以理解為基線版本,通常情況下,每次正式上線的版本都會打基線,即備份這個版本的源代碼和發布包,

以SVN為例:

新版本V1.0發布了,

源碼在這個目錄:

在tags目錄下創建以下目錄:

將發布版本的源碼Copy To到./tags/V1.0/Source Code下

在demosystem上右鍵:

TortoiseSVN->Repo-browser->

選擇這個項目右鍵:

Copy to…

輸入相應備注點擊ok即可

更新tags/V1.0這個目錄,即可獲取 Last Known Good (最后穩定的好版本)

 

 

 

10. 你的項目的源代碼和測試這些代碼的單元測試,以及其他測試腳本都是放在一起的么? 修改源代碼會確保相應的測試也更新么?你的團隊是否能部署自動構建的任務?

    在簽入之前,程序員能否自動在自己的機器上運行自動測試,以保證本地修改不會影響整個軟件的質量?

    在程序員提交簽入之后,服務器上是否有自動測試程序, 完成編譯,測試,如果成功,就簽入,否則,就取消簽入?

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

 

完善中……


文章列表




Avast logo

Avast 防毒軟體已檢查此封電子郵件的病毒。
www.avast.com


arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()