Amo Wu's Blog

如何自動化 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，你可以為每次的 release 加入說明，描述該 release 進行了哪些更改。 GitHub Releases 的基礎是建立在 Git tags 之上。Tags 代表了你的專案在某個特定時間點下的里程碑，所以它會是一個很好的 release 表達方式。 更多有關於 Git tags 的資訊可以參考 GitHub 的《 Working With Tags 》。 GitHub Releases 有什麼問題？ 我們團隊在執行 release 的過程中碰到過不少問題，總結如下： 無法回憶起曾經「新增了哪些功能」或「修復了哪些問題」，就像突然有人問「你記得上禮拜二中午吃什麼嗎？」的感覺，每次負責 release 的人都要口頭一個一個問其他工程師，最後崩潰躲在角落獨自一個人慢慢爬 commit log⋯⋯😢 Push 或 merged master 的當下就應該馬上 release Git tag，但是常常會忘記做這件事，導致之後想起來還要回去找 commit SHA 才能補上 tag 不是所有人都知道 SemVer 的版本號更新規則 Git tag 下在錯誤的 branch：因為有些 rep...

Mock Server＆契約測試 這篇文章會介紹如何運用 Mock Server 和 Integration Contract Test（契約測試）解決一些在前後端分離的開發環境底下會碰到的問題。 大綱如下： 什麼是 Mock Server？ 為什麼需要 Mock Server？ 如何使用 Mock Server？ 什麼是契約測試？ 為什麼需要契約測試？ 什麼是 Mock Server？ 下圖是傳統的前後端分離架構： 當後端 API 還沒開發完成的時候，前端會需要一個可以暫時回應假資料（mock data）的 mock server，如下圖： 等到後端的 API 開發完成之後，前端只需要將 API endpoint 從 mock server 切回 remote server 就可以使用真實資料，如下圖： 為什麼需要 Mock Server？ 一句話，因為有了 Mock Server 之後，前後端就能夠並行開發。 如何使用 Mock Server？ 這裡會介紹兩種方法： Postman Mock Service Puer Mock Server Postman Mock Service Postman 是前後端在開發上很常用到的一款 HTTP Client 應用程式，主要是拿來測試 API，除了有好用的 Collection Test Runner 之外（詳見《 基於 Postman 的 API 自動化測試 》），其實 Postman 還有提供 Mock Service 的功能，大致流程如下： 送出一個 request（R1） 儲存 R1 至 Collection（C1） 編輯 R1 的 response，儲存成為一個 example（P1） 建立一個 C1 的 Mock Server（M1） 再次向 M1 送出 R1，即會收到格式為 P1 的 response 詳細操作方法請見官方教學文章《 Mocking with examples 》。 但是使用 Postman Mock Service 會碰到一個問題，雖然 Postman 可以同時 mock 多筆 API，但是一個頁面可能會同時存在「需要 mock 的 API」和「後端已經寫好...

這篇文章會介紹如何使用 semantic-release 這個工具，自動化 Node.js (or JavaScript) 專案的版本號，以及 changelog 的 release 流程。 什麼是 semantic-release？ 為什麼要用 semantic-release？ 如何使用 semantic-release？ 什麼是 semantic-release？ semantic-release 可以自動完成下列這些事： 當 code 被 push 或 merge PR 回 production branch (ex: master) 的時候 CI build 被觸發， semantic-release 會收集此次更新的所有 commit messages（需遵循 AngularJS Git Commit Message Conventions 的格式） 自動根據 semver 的規則來更新 package.json 的 version，並建立 Git tag 自動 publish 新版本的 package 到 npm registry （非必要） 自動在 GitHub releases 的頁面上，產生相對應的 changelog 所以簡單來講， semantic-release 指的就是遵循 semver 的 release 流程。 semver 的介紹和好處可以在網路上找到很多文章，這裡就不贅述了，它的概念主要就是將版本號分成： Major . Minor . Patch 例如 React 的 0.11.2、Vue.js 的 2.0.10 等，這三個數字各自代表： Major 當你的 API 不兼容前一版本時（又稱 Breaking Change），major + 1，例如：1.x.x -> 2.0.0。 Minor 當你增加新 feature 的時候，並且不影響前一版本的 API，minor + 1，例如：x.6.x -> x.7.0。 Patch 當你修復 bug 的時候，並且不影響前一版本的 API，patch + 1，例如：x.x.9 -> x.x.10。 如果專案有在執行 git-flow 的話，minor 配合的就是 feature 的 re...

Code Coverage with CircleCI + Codecov 最近的案子用到 Redux + React ，因為它 Pure Function 的特性，所以 單元測試 很容易寫，順便也趁機會玩一下 程式碼覆蓋率 （Code Coverage）。 單元測試 Unit Test 這裡就不講單元測試怎麼寫了，網路上有很多大神的好文可以爬，我是用 Mocha + Chai ： mocha 是 test framework，提供 describe 、 it chai 是 assertion library，提供 assert 、 should 、 expect 安裝 Gulp ： npm install --save-dev gulp gulp-mocha 安裝 Babel 讓程式支援 ES6 語法： npm install --save-dev babel 加入 mocha 到 gulpfile.babel.js ： // gulpfile.babel.js import gulp from 'gulp'; import mocha from 'gulp-mocha'; gulp.task('mocha', () => { return gulp.src('test/**/*.js') .pipe(mocha()); }); 使用 npm test 取代 gulp mocha ： // package.json { "scripts": { "test": "gulp mocha" } } 這樣做的好處： gulp 可不用 -g 全域安裝 CI 會自動執行測試 程式碼覆蓋率 Code Coverage 有許多提供 code coverage review 的服務，例如： Code Climate 、 Codecov 、 Coveralls 。這裡選擇 Codecov ，因為它的 GitHub public repo 方案是免費的。 安裝 istanbul 產生 coverage report： npm insta...

這篇文章將一步一步介紹如何使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成 持續整合 與 持續交付 的開發流程。 前言 什麼是持續整合＆持續交付？ 持續整合＆持續交付（Continuous Integration & Continous Delivery），簡稱 CI & CD，具體介紹可以參考「 山姆鍋對持續整合、持續部署、持續交付的定義 」這篇文章。 簡單來說就是盡量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。 我使用了哪些工具？ Git - 版本管理 GitHub - 程式碼託管、審查 CircleCI - 自動化建置、測試、部署 Docker - 可攜式、輕量級的執行環境 AWS Elastic Beanstalk - 雲端平台 Slack - 團隊溝通、日誌、通知 看完這篇你可以學到什麼？ 瞭解 GiHub 的工作流程（ GitHub Flow ），利用 Pull Request 以及 分支 來完成 代碼審查 （Code Review）與 環境配置 ，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。 使用 Docker，統一開發者、測試人員、以及產品的執行環境。 使用 EB CLI 將應用程式部署到 AWS Elastic Beanstalk 平台上。 使用 CircleCI 將以上工作全部自動化。偵測 GitHub 分支上的程式碼，若有更新則觸發：建置 Docker 環境、單元測試、然後自動部署新版本到 AWS EB。 使用 Slack，讓團隊成員能夠即時接收 GitHub 與 CircleCI 每一項動作的通知。 內容大綱 Node.js 在本地端執行 Node.js 在本地端測試 Node.js GitHub CircleCI 在 CircleCI 測試 Node.js Code Review with GitHub Flow Docker 在 Docker 執行 Node.js 在 CircleCI 測試 Docker ...