almost 2 years ago

過去把 GitHub 只當成免費的 git repository 在用,省去自己架設 git repository server 的麻煩,但用過 CocoaPod 開發 iOS 專案後,發現很多 third-party library (例如:DZNPhotoPickerController) 不只把 GitHub 當成 git repository 而已,還是發布用的空間。最近撥了一點時間研究 GitHub 發現:GitHub 幾乎可以提供軟體生命週期管理所需的各種服務了,想當初修軟體生命週期這門課時,花不少時間研究 IBM® Rational Team Concert™,現在很多服務都可以在 GitHub 上使用,不用再自己架 server 了。

會開始研究是因為自己偶而會把一些簡單的工具類 (Utility) 程式放在 GitHub 上,但也只限於把程式碼丟上去而已,對於程式碼的狀態與管理就很少去處理,事實上很多事情都可以自動化,以自己的 SortDescriptor 專案為例,現在只有要 commit 都會自動觸發 Travis CI 進行建置和測試,另外還會跑 code coverage 工具產生測試涵蓋率的報表。有趣的是,還可以把所有的狀態都用成 badge 顯示在主頁上,因此只要進到專案首頁就會知道:最後一次建置是成功的,然後 code coverage 達到 100%。

回到軟體生命週期管理,若是小的團隊或是新創團隊,在開發軟體專案時,我個人覺得軟體生命週期管理中,較重要的有幾個環節,以及可以一起搭配使用的服務:

  • 專案管理 or 軟體開發流程管理 (Trello)
  • 持續整合 (Travis CI)
  • 版本控管 (GitHub)
  • 議題追蹤 (GitHub)
  • 建構管理 (GitHub 搭配 JCenterMaven CentralArtifactory,以Java專案為例)

GitHub 提供版本控管和議題追蹤這二個部分的功能,搭配 GitHub 的 Webhooks & Services 整合第三方的服務,像剛剛提到的,在 GitHub 整合 Travis CI,當有任何人 commit 上去就會觸發,根據 .travis.yml 腳本的設定,可以只跑測試,或是在進行 tag 的時候,將網站部署到 server 或是將套件部署到 JCenter,由於 .travis.yml 腳本也跟著一起版控,所以也比較不會有在 Jenkins 上可能會出現建置設定與程式碼不相容的情況,例如程式碼最新的版本需要新的參數設定與環境,但某個較舊的 branch 或 tag 必須使用舊的環境,否則會建置失敗的情況。這正好是滿足建置管理中,確保所有會影響到建置的環境都需要進行版控與追蹤的目標。

建構管理除了上述建置腳本的版控外,還有一個是第三方套件的版控,軟體通常都不是一個團隊能全部自己開發的,大多數情況下都會用到第三方套件,因此在 Java 的社群中,Maven 以及最近很紅的 Gradle 都有提供建構管理的相關功能,以 Maven 來說,pom.xml 檔指定第三方套件的版本,然後 pom.xml 檔隨著程式碼一起版控,建置時,根據 pom.xml 的設定, Maven 下載並使用指定的第三方套件健行建置,不會有誤用到不相容版本第三方套件的問題。

但當開發團隊開發的軟體越多時,通常會累積不少可重複使用的程式碼,此時,怎麼管理這些內部套件呢?假設這些內部套件是可以給外面使用的,那較單純,直接在 JCenter 註冊一個 repository,然後在 pom.xml 檔中加上發布的 plug-in 設定後,就可以將套件的 JAR 檔放到 JCenter 讓大眾使用, JCenter 在 Google 的加持下 (Android 套件的官方 Repository),讓不少人因無法證明擁有 group ID 所有權 (通常是要花錢去註冊 domain name) 的團隊,從 Maven Central 轉往 JCenter。

如果是私有的套件呢?可以選擇在團隊內用 Artifactory 建立一個 repository server 來管理這些套件,server 建置好後,一樣可以在 pom.xml 檔中加入布署的 plug-in,差別只是發布的位置是內部的 server。Artifactory 除了可以當套件管理的 repository 外,還可以充當外部 repository 的快取,在下載大量相依的第三方套件時 (一般來說第三方套件會相依其他第三方套件,導致要下載一大串第三方套件),縮減不少時間和網路用量。

此外,建構管理中還包含文件的管理,軟體還會需要一些文件,像是系統架構說明、設計說明等等,GitHub 的 Wiki 可以扮演文件庫的功能,同樣也能進行版本控管,只要有心,文件與程式是可以一起追蹤並管理的。例如在 merge 回 master 時,就需要同時審查程式碼與文件是否一致,若一致才能 merge 回 master 上,如此就可以確保 master 上的程式碼和文件是一致的,但這是 policy 的部分,要視團隊的需求決定是否這麼做,但就工具上是沒問題的。

在軟體開發流程的管理上,不管是使用 Scrum 或是 Kanban 方法,通常都會建議使用實體看板,但有時候電子看板還是有一些好處,像是和不同工作地點的人一起合作時就能夠協同使用。現在有蠻多雲端服務可以用的,像是 JIRATargetProcess 都可以與 GitHub 一起使用,不過上述的都算是需要付費的服務 (免費有些限制),若只是要個簡單的看板,其實可以使用 Trello,建立一個看板,然後建立 Product Backlog、Sprint Backlog、In Progress 和 Done 等列表 (下圖中的 Deployed 是針對網站服務的專案額外調整增加的,代表程式已經部署到 server 上了,可以用了) 就可以拿 Trello 當成 Scrum 的看板了。

雖然 Trello 沒有 user story 和 task 的概念,但每張 card 都還是可以有 to-do list,所以可以用 card 來描述 user story 然後在每張 card 中用 to-do list 的項目描述 task,就像下圖一樣,唯一可惜的是, to-do list 無法像 card 一樣在看板的 list 中移動作爲狀態切換 (另一點可惜的是 to-do list 的項目也無法出現在 PomoDone 中使用),但在看板上是可以看到該 story 的 task 完成的數量,還算可以接受。

到這邊,等於是以 GitHub 為中心,整合了許多網路上的服務,完成了軟體生命週期管理中較為重要的幾個項目。當然,當團隊或公司有一定的規模後,可以選擇整套的軟體生命週期管理解決方案,像是微軟的 Team Foundation Server 或是 Atlassian,只要花錢就能夠獲得完整且充分整合的方案,但新創時組合眾多免費服務的土砲也是一種不錯的選擇。而且因為是自己組合的,常常能組合出整套 solution 所無法提供的新玩法。

搞懂 Travis CI 的設定檔怎麼寫,怎麼串連 Travis CI 與 GitHub 與 codecov,如何註冊 JCenter repository (還發生過註冊錯的 group ID,得請管理員幫我改一些東西),以及和 Maven Central 打交道 (最後當然是失敗收場,因為我不想花錢去註冊一個沒在使用的網域),雖然都是一些麻煩瑣碎的事,但只要完成了,卻可以提高整體的開發效率,是蠻值得投資的基礎建設,即使不是用 GitHub,像是 GitLab 或是 BitBucket 等服務都有類似的組合可以搭配使用,因此,即使在公司內部,也能組合出這樣的環境 (最近就幫公司組合了 GitLab + GitLab CI + Artifactory + Trello Kanban)。

參考資料
https://theagilecoder.wordpress.com/2013/11/11/how-to-set-up-trello-board-for-scrum/
https://theagilecoder.wordpress.com/2013/06/08/using-trello-for-scrum/
http://willowtreeapps.com/blog/user-story-mapping-using-trello/

後記
本來這一篇是去年底就開始寫了,只是中間停擺了很長一段時間,本來是連怎麼設定都要寫上來,不過我其實也就只是照著網路上的文章不斷地試誤,而且不同專案、語言或是環境也不見得能照用,所以就不放在文章中了。

← 《精實開發與看板方法》書摘 延遲,讓Java容器更快 →