圖片來源：www.freepik.com
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
前言
過去只把 GitHub 當成免費的 code repository，省去自己架設 server 的麻煩，但用過 CocoaPod 開發 iOS 專案後，發現很多 third-party library 不只把 GitHub 當成 code 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 搭配 JCenter、Maven Central 或 Artifactory，以 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 方法，通常都會建議使用實體看板，但有時候電子看板還是有一些好處，像是和不同工作地點的人一起合作時就能夠協同使用。現在有蠻多雲端服務可以用的，像是 JIRA、 TargetProcess 都可以與 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)。
後記
印象中 2013 出社會時，業界還有不少工程師，不管是不是科班出身的，連程式碼的版本控管都做不好，更別說有落實 CI/CD 了。因此 2018 年受邀回母校北科擔任業師時，特別要求上課的學生需要將實習寫的程式放到 GitHub，並且要能在 CI 上通過測試。多年過去，最近面試時，沒有用過版本控管的人已經很少了，大多數也有使用 CI/CD，但是否跑得很順，稍微問仔細一點就知道了情況，不過，和剛出社會時相比，我覺得算是進步很多了。
