微型團隊的 web 程式開發流程

軟體工程 - 期末報告

微型團隊的 WEB 程式開發流程

N004020014 張明泰2013.06.15

大綱

● 團隊是一個 5 人內的微型的協同合作團隊。● 以 SCM 配合專案開發的流程，來管理開發專案。● 預計提出一個實務的開發的工作流程，配合 SVN 軟體來

執行 SCM 的辨識、變更管理、狀態報告及稽核等工作該。

● 軟體預計使用 Subversion Server 及 SVN Client ，配合 REDMINE(bug tracker) 來追蹤專案的執行。

● 實際使用上可能會遇到的問題及提出解決的方式。

主題

● 開發團隊的工作情境角色及開發方式說明● 開發方式遇到的問題● 解決的對策● Redmine 專案管理網站● SVN Server 及 Client 使用方式● 預期困難● 心得

(1) 開發情境

● 微型的專案團隊，一個全職其他為兼職。● 開發的環境及程式為 PHP +HTML + JS 的 WEB 程式。● 資料中心架構，以後端的 MySQL or PostgreSQL 為資料

核心。部份為 Oracle 。● 需求由專案經理溝通協調確認，透過 issue tracker 做功能

交派。● Server 平台為 Linux ，使用 FTP 上傳更新，網頁直接驗

證測試。

(1) 開發情境 - 示意圖

(2) 開發遇到的問題

● 開發者之間互相蓋掉對方的程式碼，且不知道版本的差異及改正修正哪些問題。

● 需求不斷更動，沒有紀錄不知道改些什麼。● 如果有新的成員加入專案，必須要重新說明開發的每各細

節。● 對於專案管理者，無法掌控目前的開發進度。● 測試和正式機器同一環境，安全性及穩定性有問題。

(3) 解決的對策

● 使用版本控管軟體 (svn or git) 解決程式碼覆蓋的問題。● 使用 wiki 協同作業軟體解決文件不斷更動的，讓文件的變

動可以追蹤。且可以作為對新成員的教育訓練文件。● 使用 issue(bug) tracker 來追蹤問題，使用專案管理的時

程來掌握進度。● 調整開發、測試及釋出版本的流程，並規範確實遵循。

(3) 解決的對策 - 開發關係示意圖

(3) 解決的對策 - 角色

● 專案經理：即是首席程式設計師擁有所有平台環境的存取管理權限。 ( 首席程式設計師團隊 P367)

● 開發人員：兼任測試人員，可以 commit 各版本到 Testing 平台，並且自行測試功能正常沒有問題後，就可以自行 Release 正式發布的平台。

● 報告人員：只擁有 Redmine 專案平台的問題回報權限，工作的分派由專案經理分派或開發人員認領。

(3) 解決的對策 - 需求已確認的開發流程

● 專案經理確認需求及功能，以 REDMINE 的建立問題 -> 功能說明需求。

● 開發者再本地端建立一個開發者使用的測試環境，所有的測試都在這裡地方。

● 本地端程式碼的編寫測試更新都透過 svn client 上傳更新到 svn 儲存庫中。

● 當測試到一個段落，將程式碼放到 Testing 的 LAMP 平台上，測試人員進行測試。

● 如果有問題，測試人員再 REDMINE 上面填寫問題回報，系統會以 Email 通知開發人員。

● 開發人員接件，解決問題。專案經理再過程中全程協調監控所有的活動狀態。

● 當測試沒有明顯的問題後，就進行 Release 程式更新到正式的 LAMP 平台上面。

● 完成一個 Release 後，再 REDMINE 上編寫這個里程碑的文件。( 文件的編寫程式過程中，就和程式碼寫在一起，整理文件再整個 review 一次 )

解決的對策 - Redmine 專案管理平台

http://redmine.jangmt.com/http://redmine.jangmt.com/

(3) 解決的對策 - Redmine 專案管理平台

● Redmine 功能清單 (ref:RedMine Features)

● Per project wiki - 每個專案獨立 Wiki 系統

● Per project forums - 每個專案獨立 討論區

● SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs) – 支援多種版本控制系統

● Multiple projects support - 可以開多專案管理

● Flexible role based access control - 多種角色的存取控制

● Flexible issue tracking system - 議題追蹤管理

● Gantt chart and calendar - 甘特圖自動生成、行事曆

● News, documents & files management - 文件、檔案管理

● Feeds & email notifications - RSS 、 Email 通知

(3) 解決的對策 -RedMine活動

● Activity

● 可以知道最近專案的活動狀態。

● 包含問題處理、文件編寫、程式碼更新等 ....

(3) 解決的對策 - RedMine 問題清單及新問題

● 可以針對 BUG 或議題或變更管理並且給予追蹤及確認的後續流程。

● 此功能定位為紀錄每個變更事件發生時候詳細紀錄。

● 可以用 mail 追蹤這個問題的處理狀況。

● 可以分派這個工作給開發人員，可以安排預計規劃的工作時程。並且與甘特圖結合。

(3) 解決的對策 - Redmine甘特圖 or 日曆

● 甘特圖和日曆可以協助安排專案的時程，視覺化顯示專案的進度。 .

(3) 解決的對策 - RedMine 的 wiki

● WIKI 可以用來記載需求文件及需求變更的管理。且以系統化的方式紀錄。

● 因為可以查詢版本變化的過程，所以適合需求變更的軟體專案開發活動使用。

● 和問題追蹤不同處在於可以系統化的紀錄專案。

(3) 解決的對策 - Redmine 儲存庫

● 可以結合 SVN or GIT 等外部的版本控管系統，同時知道程式碼的變更狀況。方便稽核程式碼。

● 可以再 web 上 diff 比較檔案。

(3) 解決的對策 -SVN 版本控制系統

● 使用 SVN 版本控制系統的原因：● 可在協同開發創作的環境中可以保有所有的變動紀錄、回復到指定的版本、成員的程式更動與其更動狀況紀錄。

● SVN 是集中式的版本控制系統，需要網路才可以更新。● 其他的版本控制系統： GIT( 分散式版本控制系統 )

(3) 解決的對策 -SVN 軟體及使用原則

● Windows 上常見的工具有 TortoiseSVN

● Linux 上推薦 RapidSVN (GUI) 及命令列 SVN

● Repository ：儲存放置文件的儲存庫或資料庫● SVN 可以透過 http 、 https 、 ssh+svn 、 svn 等方式存

取。 Ex: svn://svn.jangmt.com/home/repos/test/

● SVN 目錄習慣上分成為 Trunk/Tags/Branches 。

(3) 解決的對策 -SVN原則

● Trunk: 版本主幹，主要開發都在這裡● Tags: 可以依據里程碑或 Release 的版本

分支成為 Tags

● Branches: 通常用於功能點的分割或 bug 的修正。完成後使用 Merge 合併回 trunk 。

(3) 解決的對策 -SVN 功能 (1)

● Svn Checkout 將 SVN 儲存庫中的資料取出

● Svn Update 更新 svn 上面的版本到最新

● Svn Commit -m ' 說明 ' 提交修正的內容

● Svn add 將檔案或目錄加入 svn 儲存庫，需要 commit 後才會生效。

● Svn mv 改檔名

● Svn status 顯示上次 update 後的檔案狀態 , 有 conflict 也會顯示。

● 常見的 SVN 檔案狀態 : A - 新增檔案C -檔案和儲存庫不同，合併失敗需要人工介入處理M - 有修改過得檔案? - 新的檔案不在儲存庫中

(3) 解決的對策 -SVN 功能 (2)

● Svn revert 目錄 /檔案 還原為前一個版本

● Svn info 顯示目前 SVN 的相關資訊

● Svn resolved 處理 conflict 的狀況 , 否則 commit 都會出問題

● Svn diff 比較目前的檔案和 SVN 儲存庫的不同處

● Svn copy 可以用來建立 Branch 分支或 tags 保存版本狀態。

● Svn import 將本地端來源匯入 svn 儲存庫

● Svn log 顯示 commit 的 log 狀態

● Svn lock 鎖定檔案

● Svn unlock 解除鎖定

(3) 解決的對策 -SVN原則

● 同時間只有一個人的開發方式：● 直接對 儲存庫的 trunk 主幹作 commit ，先上 Testing

平台測試，沒問題後再 svn update 到 Release 的平台。● Redmine 的文件及 issue 解決仍是需要回報。

(3) 解決的對策 -SVN原則

● 修正 bug 的方式：● 1. 先作 svn update 將程式碼更新到最新版本● 2. 檔案較少可以 lock 該檔案，修正後重新 commit 到

Testing 機器。沒問題後再 Release 小版本修正。● 寫功能的方式：● 1. 先作 svn update 將程式碼更新到最新版本● 2. 寫功能一定要 copy a branches ，測試完成後再

merge 合併回 trunk 。

(3) 解決的對策 - 資料庫的對策

● 因為使用資料中心的架構的開發方式，資料庫資料是核心的一環。

● 讓開發者可以存取維護三個不同開發流程中的資料庫，但在資料上以每日或每 6小時備份的方式避免發生不可逆轉的意外。

(3) 解決的對策 - 開發方式原則

● 參考極限編程的流程。遵循期核心價值：溝通、簡單、回饋、勇氣，掌握基本原則。

● 再遵循原則流程中，放手讓開發人員去開發，確保資料可以回朔保存，最多損失一天的開發量。

● 一次不用寫太多，分成小功能逐步編寫。● 寫程式就同時寫註解，但是要避免亂寫。● Code 要有一定的水準才提交，提交要有責任感。

(3) 解決的對策 - 開發方式原則

● 一定要遵循測試開發的流程，謹慎的開發流程 Policy 可以減少爆肝修 bug 的次數。 ( 不要在下班前 2小時 Release code)

● 每次開發以 3HR左右為一個短循環，立即驗證且得到回饋。要求每次短循環的開發都要寫下文件。 ( in Issue tracker or wiki )

● 以人性的角度思考程式碼及功能，不要做出違反人性的工作及程式。

(4) 預期困難點

● 開發人員會因為時程壓力或怕麻煩而沒有遵循這樣的開發流程規則。

● 此種開發模式類似極限編程方式，需要有獨當一面的開發人員。

● 開發人員的 code style 不好規範，寫出來的程式很難重複使用。

● 不能使用程式框架這會讓新進人員的學習曲線過高。● 整合的開發環境，開發人員無法熟悉每個環節。

(5) 心得

● 對於團隊的軟體的開發流程，實務上沒有經歷過合作或遇到問題沒辦法準確的抓出問題的所在。

● 迎合實際的工作環境，設計出自己執行上合理的維護流程，我想是這門課給我最大的收穫。

報告完畢