最近剛好在跟以前一起工作過的朋友聊到薪資的問題，提到產品設計師的薪資水準比軟體工程師的最高薪資，大概差了一倍左右，這讓我覺得非常疑惑。

以一間做產品為主的公司來說，產品的設計會嚴重的影響公司收入，但拿到的待遇卻沒有比工程師還高，是不是哪裡出了問題？

前幾天在 Facebook 社團 Ruby on Rails 新手村看到有人提問關於 Mock 和 Stub 的問題，其實問題本身很簡單，不過也讓我發現雖然我們都知道該寫「測試」但很多時候是不清楚怎麼撰寫的，這篇文章會先來分享一下我對 Mock 的看法，更詳細的 RSpec 測試系列請期待明年的「優雅的 RSpec 測試」連載。

當我們完成部署後是一個更大的任務開始，我們仍然還有許多的任務需要處理。舉例來說，我們還需要對網站加入各種類型的監控，並且持續的追蹤各項指標（Metrics）的變化，持續的改進。

Review Apps 是 GitLab 所提供的一個機制，可以用於針對某個 Merge Request（合併請求）來自動部署給用來進行 QA（Quality Assurance）驗證或者專案經理檢查功能的機制。因為我們已經可以進行自動化的部署，也因此可以用來產生 Review Apps 進行驗證。

Heroku 也有提供 Review Apps 的方案可以跟 GitHub 搭配，可以根據需求調整。

當我們從 Docker Compose 轉換到 Docker Swarm 之後，仍然還是面臨需要人工進行部署操作的狀況，因此我們還需要更近一步的利用 GitLab CI 來幫助我們解決部署的人工操作。

部署的環境已經準備好後，我們就可以來將之前所撰寫的 Docker Compose 設定檔轉換為 Docker Swarm 支援的格式，以及調整我們的架構來讓專案可以被部署到 Docker Swarm 上面。

要使用 Docker Swarm 還是需要進行一些設定，相比過去的 Docker Swarm 這幾年使用上容易許多，基本上只需要兩個命令就可以完成安裝。

雖然我們可以用 Watchtowner 來實現自動的部署，然而這樣的方式還有許多問題存在。首先是我們基本上無法控制版本，只能抓取 latest 的版本，除此之外也無法控制部署的時機以及退回的機制。

這個時候我們就可以導入 Docker Swarm 來作為替代方案，作為轉換到像是 AWS ECS 或者 Kubernetes 的過度方案。

為了要能夠實現持續部署，我們除了將專案準備好之外，還需要能夠將 Rails 自動的部署到我們想要部署的伺服器上。

採用容器技術的話就不需要煩惱環境的問題，只需要有能夠運行容器的環境即可，在測試環境或者簡單的小專案就可以使用 Watchtowner 來幫助進行部署，是一種非常簡單又快速的方式。

GitHub Actions 跟 GitLab CI 有著不少差異，雖然在這類工具中不外乎就是生產線（Pipeline）和任務（Task）的搭配使用，然而每套系統都還是有著不同的設計可以使用。

因為我比較常使用 GitLab CI 因此有著完整的樣板專案可以使用，目前還在建置 GitHub Actions 的樣板，這篇文章主要是我在 GitHub 上面的專案所彙整出來的使用技巧。