BugPhobia團隊篇章：團隊管理與Github源代碼管理說明

0x00：序言

To the searching tags, you may well fall in love withhttp://xueba.nlsde.buaa.edu.cn/

再見，無憂時光~

 

0x01 ：BugPhobia團隊的協做與分工

團隊在Beta階段將完成使用Team@OSC進行任務的管理（https://team.oschina.net/Bugphobia）和Github自己的Issues進行關聯

0x0100：團隊任務處理流程

n  團隊所有成員均可以發佈任務，但必須保證任務標籤、任務說明均完備，在發佈後任務將自動進入待辦中狀態 n  全部預約任務均會在兩天前發佈任務，團隊的少年/少女在完成任務時應當首先將任務狀態更改成進行中狀態，而任務完成後可自行將任務狀態更改成已完成（或者在Scrum Meeting上說明情況，由其餘人歸爲「已完成」狀態） n  狀態進入「已完成後」，任務管理將進入「審閱階段」，此階段將由項目經理審閱後更改成「已驗收」狀態，此後項目經理將同期發佈代碼複審工做

n  團隊各少年/少女，必定要在每晚22點左右關注https://team.oschina.net/Bugphobia/，任務將按期發佈在這裏，必定要保證任務不會被遺漏！ n  注意：團隊的全部項目，必須創建在XuebaOnline的任務下 n  文檔必定要上傳至completed文件夾，待審閱完成後將由錢林琛自動遷移到documents文件夾（後期的整理交由項目經理完成）

 

0x0104：團隊文檔管理：組內監督

 

團隊文檔管理說明：

團隊自主交流文檔儘量使用**Markdown**文本編輯，容許使用擴展的Markdown語法，但必須保證GIT@OSC或MarkdownPad可以支持相應的擴展語法

對於部分必要的新技術（Semantic UI，ReactJS，Django，Apache部署等等），必須同時維護一份技術入門文檔，**此文檔容許延遲或交付其餘人完成**（如Semantic UI的開發維護能夠由Panacea完成），但必須保證各個文檔有人維護，須要包含如下基本信息： n  參考資料或連接（特別鳴謝） n  常見問題的解決 n  入門教程 n  撰寫人，維護人，修改時間和版本說明

文檔容許工做轉交，但必須保證責任人惟一制度，同時容許協同合做完成

項目經理將依據文檔的維護狀況進行進度的基本調整，同時文檔最後必須由項目經理整合爲一份合格的開發文檔

 

團隊文檔管理說明：

前端	n  對於每一ReactJS渲染的頁面，要求必須存在獨立的維護文檔，若是某幾個頁面關聯性強，容許將幾個頁面合併爲一份文檔進行維護，但必須包含文件路徑，文檔說明，維護人等等 n  Semantic UI入門教程（含HTML,CSS） n  ReactJS入門教程
後端	n  對於各個接口定義，要求必須存在必定的維護文檔和單元測試！同時提供單元測試/技術文檔的說明，此部分文檔在後期會進一步做出說明 n  Django入門教程,Solr、Apache、Nutch等的配置
團隊總體	n   [直接負責人：錢林琛] 功能規格說明書 n   [直接負責人：錢林琛] 需求分析說明書 n   [直接負責人：王鹿鳴] 前端規格說明書 n   [直接負責人：馮志睿] 後端規格說明書 n   [直接負責人：李雲濤] 測試規格說明書 n   [直接負責人：王文基]環境規格說明書（Solr）

 

0x02 ：BugPhobia團隊源代碼管理解決方案

 

0x0200：文檔完備性說明

問題

ü  若是你的團隊來了一個新隊員，有一臺全新的機器， 大家是否有一個文檔，只要設置了相應的權限，她就能夠根據文檔，從頭開始搭建環境，併成功地把最新、最穩定版本的軟件編譯出來，並運行必要的單元測試？

 

回答

Github項目傳送門：（https://github.com/bugphobia/XuebaOnline/blob/master/README.md）

n  圖1爲學霸WEB端的項目的目錄結構說明，從開發人員的角度可以快速瞭解項目的全局架構；而因爲在Beta階段BugPhobia團隊自己和Dream團隊協做開發後端，而根據協做開發的Dream團隊成員反饋，可以依據提供的項目的目錄說明，快速上手開發這一項目 n  同時，圖2爲學霸WEB端的環境配置手冊，根據環境配置指南可以清晰地完成Windows平臺和Linux平臺的環境搭建，同時通過團隊成員在Windows 7/10、Ubuntu 12.10/14.10等操做系統平臺搭建，均完成了團隊項目的最新版本的穩定編譯結果；而對於單元測試方面，因爲團隊前端項目爲服務器等方面的壓力測試腳本，閉源處理而由測試人員處理，所以前端方面的測試沒法交予新成員，然後端方面，直接選取Django框架自己提供的單元測試，進行必要的測試工做（參考學習資料：http://www.ziqiangxuetang.com/django/django-test.html）

圖 1 XueBaOnline項目目錄結構說明

圖 2 XueBaOnline項目環境配置手冊（含Windows平臺和Linux平臺）

 

0x0204：源代碼管理和文件鎖定

問題

ü  你的團隊的源代碼控制在哪裏？用的是什麼系統？如何處理文件的鎖定問題？ 場景： 程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候，程序員小飛也要改其中一個文件，快速修復一個問題。怎麼辦？ 一個代碼文件被簽出 (check out) 以後，另外一個團隊成員能夠簽出這個文件，並修改，而後簽入麼？ 有幾種設計，各有什麼優缺點？ 例如，簽出文件後，此文件就加鎖，別人沒法簽出；  或者， 全部人均可以自由簽出文件

 

回答

n  團隊項目在Github上託管，採用git的方式進行版本控制，這個是咱們在開發伊始就達成的共識，針對這種多人多任務的開發模式，咱們認爲git是再好不過的選擇，因而咱們從開發到如今一直採用這種方式；而團隊管理則選取Team@OSC進行管理，保證issues和團隊開發進程緊密相連 n  團隊的在處理文件的鎖定問題上是不加鎖的，也就是說咱們的成員能夠自由遷入遷出。因爲現階段的開發規模比較小，因而爲了最大化效率，咱們沒有對文件遷入遷出進行過多的限制。將文件在遷入遷出時加鎖，顯然能夠保證源代碼修改的同步性，減小沒必要要的衝突和錯誤，可是這樣的缺點是顯而易見的，因爲缺少了並行性，項目開發的效率就被極大地下降了，極端狀況下頗有可能由於一我的的失誤，致使全隊項目的擱淺。反之，咱們採用自由遷入遷出（用鄒欣老師的話來說，就是「寬鬆的政策」）的方式，則與前者的優缺點互反了

圖 3 XueBaOnline項目源代碼管理展現圖

 

0x0208：版本差別和文件瀏覽

問題

ü  如何看到這個文件和以前版本的差別？ 如何看到代碼修改和工做項 （work item），缺陷修復 （bug fix) 的關係 場景： 程序員果凍看到某個文件被修改了，他怎麼看到這個文件在最近的修改究竟改了哪些地方？ 場景： 程序員果凍看到某個文件在最新版本被改動了100 多行， 那麼和這100多行對應的其餘修改在什麼文件中呢？ 這個修改是爲了解決哪些問題而做的呢？ 那些問題有工做項 （work item，issue），或者bug 來跟蹤麼？

 

回答

n  如圖4所示，git pull進行更新後，能夠看到本地的版本和最新的版本之間的不一樣之處 n  如圖5所示，同時，在本地上傳本身的文件到分支以後也能夠查看本身或者是別人上傳的文件在之前的版本的基礎上，修改了哪些地方

圖 4 Github本地版本和更新版本的不一樣效果展現圖

圖 5 Github中commit記錄對增刪改查的記錄展現圖

 

n  如圖6所示，點開項目的commit的記錄，點擊相應的SHA版本哈希值以後能夠進入到以下的頁面 n  如圖7所示，咱們在上面圖片裏面能夠看到的是"+"標註的是在原文件的基礎上增長的代碼的記錄，"-"標註的是在原文件的基礎上刪掉的代碼的部分，顏色顯示也不一樣。其實咱們團隊是以任務爲單位和模塊進行的開發，這種開發模式在任務分配之處就已經給該任務提供了描述

圖 6 Github的具體commit記錄展現圖

圖 7 團隊任務開發模塊中映射於Github的任務描述展現圖

 

n  如圖8所示，以後在完成任務push以前還要在commit時加上任務完成狀況的描述，方便咱們在之後經過git log指令產看相應的git的記錄。這樣的雙向映射的機制保證了咱們每一次提交的版本目的明確，特徵鮮明。

圖 8 Github的具體log機制展現圖

 

0x020c：文件合併說明

問題

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

 

回答

n  在git中執行合併便可自動合併Git修改的部分。可是，也存在沒法自動合併的狀況。若是在遠程數據庫和本地數據庫的同一個地方都發生了修改的狀況下，由於沒法自動判斷要選用哪個修改，因此就會發生衝突。 git會顯示本地數據庫和遠程數據庫同一個地方的不一樣修改，這時候就須要咱們手動解決衝突，暫時沒有想到什麼好的工具能夠解決不借助人力自動解決這個問題，只能依據規定和協商解決這一問題。

圖 9 Git中的衝突解決方案說明展現圖

 

0x0210：修改原子性解決方案

問題

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

 

回答

n  git做爲一個成熟的源代碼版本管理系統自己就能夠保證在簽入時的原子性，因此在咱們的項目開發流程中沒有遇到部分修改能夠上傳而某些部分的修改不能上傳的混亂狀態。

圖 10 Git簽入原子性保證展現圖（管理系統自己的特性）

 

0x0214：BUG緊急修復

問題

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

 

回答

n  這個時候咱們只要在本地新建一個分支，而後在新的分支上進行bug的修復就好。當前分支的內容就被保存在原地。過程如圖11所示，這樣咱們就能夠在「乾淨」的環境中進行bug的修復工做了。

圖 11 Git的BUG修復解決方案/分支新建解決方案展現圖

 

0x0218：源代碼分支創建

問題

ü  如何給你的源代碼創建分支？ 場景：大家須要作一個演示，因此在演示版本的分支中對各處的代碼作了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 大家怎麼作到的？ 在演示以後，演示版本的有些修改應該合併到主分支中，有些則不用，大家是怎麼作到的？ 場景： 大家的軟件發佈了，有不少用戶，一天，一個用戶報告了一個問題，可是他們是用某個老版本，並且沒有條件更新到最新版本。 這時候，你如何在本地構建一個老版本的軟件，並試圖重現那個問題？

 

回答

n  新建分支的工做在上一個問題中已經闡述過了，這裏面咱們看到其實兩個場景面臨的都是版本回退與復原的問題。這一點咱們的git有很完美的解決方案，那就是採用git reset指令或者是採用github上的版本回退的機制（如圖12的示意圖） n  如圖13所示的回退版本以後的頁面，這樣，咱們就能夠利用這種機制進行版本的控制和管理，記錄每個點滴的瞬間，不讓任何的狀態隨着歲月蒼老流逝

圖 12 github版本回退的圖形化界面說明圖

圖 13 Git版本回退後的界面展現圖

 

0x021c：文件修改記錄說明

問題

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

 

回答

n  這個問題有一部分是和上面的問題重複的，對於咱們團隊來說每一次的任務都會被項目經理提早打上標籤，並且在最後的簽入的時候會有commit的記錄保留，因此每一次的提交均可謂是目的明確，特徵顯著。至於「追責」問題，github上面有每一次的每個人的提交的記錄，對應着很是容易找到相關負責人。

圖 14 文件版本修改責任管理說明圖

圖 15 文件版本任務流程追蹤說明

 

0x0220：源文件版本控制

問題

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

 

回答

n  這個在每一次提交的時候還真沒有特別的標記，以前咱們通常會採用兩方式獲得「Last Known Good」的版本的代碼，一個是根據任務完成時候的commit記錄中推測這個版本會是哪個，還有的更多的是daily scrum meeting的時候你們討論後相互通知，告訴成員，哪一個版本是最好的 n  從咱們的任務分配上仍是能推測得出來問題解決到哪一步了

圖 16 團隊項目進展標籤說明（Scrum Meeting間必需要探討這一問題，以此展開）

 

0x0224：源代碼與測試協調管理

問題

ü  你的項目的源代碼和測試這些代碼的單元測試，以及其餘測試腳本都是放在一塊兒的麼？ 修改源代碼會確保相應的測試也更新麼？你的團隊是否能部署自動構建的任務？ ü  在簽入以前，程序員可否自動在本身的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？ ü  在程序員提交簽入以後，服務器上是否有自動測試程序， 完成編譯，測試，若是成功，就簽入，不然，就取消簽入？ ü  團隊是否配置了服務器，它自動同步全部文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊

 

回答

n  團隊並未選擇自動測試的框架，也未在Git上支持自動測試；團隊在開發初期就約定測試腳本徹底閉源，所以測試均是在本地由各模塊地開發者自行手動測試；而先後端對接後的頁面，在保證編譯和運行正常進行的狀況下，本地完成相應的黑盒或白盒測試，而在測試經過後佈置在服務器端完成必要的安全和壓力測試