如何自動化 GitHub Releases 流程

如何自動化 GitHub Releases 流程

2017 年初的時候，曾經寫了《如何自動化 release 的流程？》這篇文章，介紹了如何利用 semantic-release 和 TravisCI 自動化 GitHub Releases 和 NPM publish 這件事。這次要介紹的是如何直接透過 Probot 機器人做到 GitHub Releases。

大綱

  • 什麼是 GitHub Releases？
  • GitHub Releases 有什麼問題？
  • 什麼是 Conventional Commits？
  • 什麼是 Conventional Release Bot？
  • 為什麼要用 Conventional Release Bot？

什麼是 GitHub Releases？

GitHub Releases 是 GitHub 提供給每個專案在釋出（Release）新版軟體時，用來紀錄更新內容（Change Log）的頁面。

GitHub Releases
GitHub Releases

通過 GitHub Releases，你可以為每次的 release 加入說明，描述該 release 進行了哪些更改。

GitHub Releases 的基礎是建立在 Git tags 之上。Tags 代表了你的專案在某個特定時間點下的里程碑，所以它會是一個很好的 release 表達方式。

更多有關於 Git tags 的資訊可以參考 GitHub 的《Working With Tags》。

GitHub Releases 有什麼問題？

我們團隊在執行 release 的過程中碰到過不少問題，總結如下：

  1. 無法回憶起曾經「新增了哪些功能」或「修復了哪些問題」，就像突然有人問「你記得上禮拜二中午吃什麼嗎？」的感覺，每次負責 release 的人都要口頭一個一個問其他工程師，最後崩潰躲在角落獨自一個人慢慢爬 commit log⋯⋯😢
  2. Push 或 merged master 的當下就應該馬上 release Git tag，但是常常會忘記做這件事，導致之後想起來還要回去找 commit SHA 才能補上 tag
  3. 不是所有人都知道 SemVer 的版本號更新規則
  4. Git tag 下在錯誤的 branch：因為有些 repository 的 default branch 會設為 develop，但是常常忘記選擇 master
  5. Git tag name 打錯字：不是忘記加 v（例如 1.1.0 ）就是多一個點（例如 v.1.1.0 或 v1.1.0. ）◢▆▅▄▃ 崩╰(〒皿〒)╯潰 ▃▄▅▆◣
  6. 即使上面的步驟都讓你做對好了，但是下一次要 release 還是得手動再來一遍⋯⋯這種彷彿在玩疊疊樂，希望積木不要倒的心情，我覺得不行

什麼是 Conventional Commits？

Conventional Commits 是 conventionalcommits.org 在維護的一份 Git commit message 規範。

Conventional Commit 定義的 commit message 結構應該如下：

<type>[optional scope]: <description>

[optional body]

[optional footer]

根據 commit message 的不同，產生的 release 內容也會有所不同：

  • Bug Fixes：當 type 為 fix，那麼它屬於「修復問題」類型的 commit（等同於 SemVer 的 PATCH）
  • New Features：當 type 為 feat ，那麼它屬於「新增功能」類型的 commit（等同於 SemVer 的 MINOR）
  • BREAKING CHANGES：當 body 或 footer 的開頭有出現 BREAKING CHANGE: 這個關鍵字，那麼它屬於「會讓舊版程式無法運行的更新」類型的 commit（等同於 SemVer 的 MAJOR）。一個 breaking change 的 type 只能是 fix、feat 或 chore。

Scope 為選填內容（使用括號包在內），它可以協助 commit 提供額外的上下文資訊。例如：

feat(component): add brand button

Commit types 除了 fix 和 feat 之外，其它 types 也是允許的，例如 Angular convention 建議的 docs、style、refactor、test 和 chore，但是這些 types 僅供閱讀方便使用，並不會出現在 release notes 之中。

遵循 Conventional Commits 之後，整體的 commits log 感覺大致如下：

更多細節可以參考 Conventional Commits Specification。

什麼是 Conventional Release Bot？

Conventional Release Bot 是 Hahow 開源的 GitHub 機器人，它能夠根據 Conventional Commits 的規範，自動幫你產生 GitHub Releases 和 Git tags。

Bot 自動產生的 GitHub Releases
Bot 自動產生的 GitHub Releases

如上圖所示，Conventional Release Bot 自動產生的 GitHub Releases 內容如下：

  1. Git tag（遵循 SemVer）
  2. Release 日期
  3. Release 類型：Bug Fixes、New Features 和 BREAKING CHANGES
  4. Conventional Commit 的 scope（有填寫才會出現）
  5. Commit 說明
  6. Commit SHA
  7. Commit 作者
  8. 和上一版本的 diff

如果機器人沒有在 commits 裡發現 feat、fix 或 BREAKING CHANGE，則會跳過建立 GitHub Releases 的步驟。

為什麼要用 Conventional Release Bot？

總結一下 Conventional Release Bot 的優點：

  • 自動化產生 CHANGELOG（GitHub Releases）
  • 自動化更新 SemVer 版本號（以 Conventional Commits 的 types 為基礎）
  • 通過友善的結構化 commit 規範，讓開發者更容易瀏覽更新歷史，提高對專案做出貢獻的意願
  • 更好地向人類（同事、使用者或其他利益相關者）傳達軟體更新的本質

最後，Conventional Release Bot 的原始碼＆安裝方式可以在 amowu/probot-conventional-release 找到，歡迎大家一起來貢獻 Pull Request。😘

留言

張貼留言

這個網誌中的熱門文章

COSCUP 2012

今年很幸運的有搶到入場資格，這也是小弟第一次參加 COSCUP ，趁現在剛結束滿腔熱血的狀態下來寫篇心得文。 今年 COSCUP 一共有兩天的行程，在中研院人文館舉辦，每個時段都有 3~4 場的分享，不過常常碰到某個時段三場都想聽，也常常碰到某個時段的題目都沒興趣...orz Day1 第一天忘了做筆記，只好憑記憶跟拿些圖來湊一湊 我的專屬識別證唷>.^ 早上第一場是微軟傳教士分享的 Windows Azure 感覺還不錯，而且有繁體中文的介面。 第二場我去聽了 Fred 的 Nodee.js OS，不過我覺得他自己改的 Linux 比較炫。 第三場請到 Penk 大大來 demo 他的平板 UI，印象深刻的一句話是 科技業是唯一比女行時尚還追求時尚的行業 我的解讀是幹這行每天都在學新技術 囧.. 第四場超讚，講者 demo 他用 javascript 寫的超任模擬器，眼淚都快飆出來了，而且老師很幽默: 目前國外有人正在研究如何用 javascript 寫出一個超任模擬器，如果他成功，那會是全世界第三個，因為前面兩個被我寫出來了XDDD 接下來的下午場雖然都有去聽，可是比較沒有什麼印象的點，只記得最後閃電秀的大大們XD，你們實在太讚了! Day2 難得有位置，明明很晚到... 第一場請到廣達的 Ted 先生，本來以為會很無聊，但從頭聽到尾，學到蠻多東西的: 研發的目的 1.不想被外界surprise 2.想給外界surprise   不相信外星人就無法創造飛行車   要把複雜的東西變簡單其實是最不簡單的   設計一個你最討厭的東西 試著把它做好 第二場去聽 Tool Objects in jQuery，主要重點: 用 Queue 取代巢狀 Callback Deferred 可以看做是 Call by future  $.when 可以用來管理複數非同步的結果  pipe 跟 when 的關係可以看作串聯與並聯 一些 Callback 常用的 function: add fire once memory unique stopOnFalse differed 第三場的場次是我最掙扎的，有Heroku，有Emacs，有Twitter Bootstrap，還有手
閱讀完整內容

Hahow 為什麼沒有 iOS App

圖片
大綱 前言 Hahow 為什麼沒有 iOS App？ 為什麼有了「App 內購買」還是被拒絕？ 為什麼 Hahow 要使用「消耗型項目」IAP？ 為什麼 Udemy 可以使用「消耗型項目」IAP？ Hahow iOS App 接下來的計畫？ 結語 前言 最近看到一篇 The Verge 報導 ，Apple 的律師要求 App Store 的前任經理停止發行《App Store Confidential》這本書，因為此書透露了「重大的商業機密」，違反了員工與公司簽訂的合約。 但是此書的作者 Sadowski 表示，這本書的很多內容其實是大家都知道的，例如：應用程式必須將使用者轉化為 Apple 的 付費客戶。 來源 appleinsider 眾所周知，Apple 的 App Store 平台審核機制封閉，很多東西是他們說的算。 作為一位曾經參與 Hahow App 的開發人員，看到這一篇報導感觸很深，滿肚子苦水不吐不快。 許多 Hahow 的使用者常常詢問，為什麼 Android 的 App 已經上架這麼久了，iOS App 卻還看不見影呢？ https://hahow.app Hahow 為什麼沒有 iOS App？ 其實 iOS App 一直都是與 Android App 同步開發的。 最早可以回朔到 2017 年 10 月，當初 Web 使用者不斷反應，希望可以在手機上，下載 Hahow 的課程，方便通勤時間也能離線觀看。 於是我自己利用公司讀書會的機會，嘗試使用 React Native 開發了一個 Hahow App 的原型（Prototype），簡單演示了「下載離線觀看」和「通知」兩個手機上才能做到的功能。 Prototype 讀書會簡報 也因此，成功說服了幾位頭頭，於 2018 年 2 月正式投入開發 Hahow App。 並於 2018 年 6 月，順利在 Google Play 上架 Android App。 有關於我們如何用 Expo 這個 React Native SDK 開發 App、踩過哪些坑，以及專案的 Scrum 怎麼跑之類的，會再另外找時間分享一篇《Hahow 如何開發 Android App》文章，這裡就先不多贅述。 Go
閱讀完整內容

swfobject - 網頁輕鬆嵌入Flash

Flash在網頁上的應用已經越來越普遍了，未來一樣占有一席之位，但是從以前到現在，對於發佈Flash到網頁上常常碰到一些不必要的問題，例如XP SP2更新後，IE瀏覽器上方會出現檔掉的訊息，或是Flash外框出現虛線，需要滑鼠點一下才能開始動作等...，而且使用者並未安裝Flash Player的情況下或版本太低都會無法順利的瀏覽。 最近剛好看到一個不錯的東西，就是這次要介紹的swfobject，一般我們要嵌入swf到HTML時，通常會寫的語法如下: < object id ="FlashID" classid ="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width ="300" height ="120" > < param name ="movie" value ="test.swf" /> < param name ="quality" value ="high" /> < param name ="wmode" value ="opaque" /> < param name ="swfversion" value ="6.0.65.0" /> </ object > 上面的程式碼使用到<object>標籤，早一點的甚至還要再寫<embed>才能動作，因為IE跟其他瀏覽器的種種原因，使得這種寫法不但又臭又長，也不符合標準。 那使用swfobject有什麼好處呢?我們繼續看下去吧。 首先我們得先去swfobject的網頁 http://code.google.com/p/swfobject/ ，然後下載目前的最新版本 swfobject_2_2.zip 。
閱讀完整內容