Heresy 這邊在去年架設好自己的 GitLab 後，都有固定在更新，同時也在試著研究之前沒用上的功能、看看到底有沒有幫助（例如 Gitlab CI/CD）。
由於自己採用的是 Docker 的形式（Omnibus GitLab），所以其實不管是安裝、升級，都算是相對簡單的；但是在升級到前幾天推出的 GitLab 13 的時候，倒是小出包了一下…
GitLab 13 的新功能，可以參考官方的《GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS》這篇介紹。
而這邊踩到的地雷，則是他把預設的網頁伺服器，從 Unicorn 改成 Puma 了。
之前有說過了，Heresy 為了自己在玩的手機遊戲《刀劍神域－記憶重組》另外弄了一個部落格來做紀錄（網址）。
而實際上，之前由於覺得遊戲內的公告由於不是照著更新時間排序、要找到哪個公告是新的實在很麻煩，所以就火大，自己試著想辦法去做公告的變更紀錄了。
搞了老半天，弄出了一個使用了兩個 Git repository 的奇怪架構系統，算是勉強做到堪用的程度了～
目前的成品是：https://kheresy.github.io/SAOMD-AA/changelog.html
而實際在運作的專案則是 https://gitlab.com/kheresy/saomd-announcement
目前 Google 和微軟都有提供線上翻譯的服務，甚至很多網站也會直接把翻譯的功能掛進去。
像是 Twitter 其實就有掛了 Google 翻譯的連結，使用者可已在不離開頁面的情況下，看到翻譯的結果。
但是根據自己的經驗，其實 Google 翻譯在把日文翻譯成中文的時候，其實結果實在很難說是夠好…很多時候，看著翻譯的結果，常常會覺得不但文法詭異到一個極致，就算想自己重新拼湊、也還是無法理解它的意思。
而這次在《DeepL 翻譯器新增中文日文，更接近真人流暢語意的翻譯品質》這篇文章看到的 DeepL，感覺則是提供較好的翻譯結果了！
Docker（官網）這種比虛擬機器更輕量化的「容器」虛擬化技術，基本上算是這幾年來一個滿重要的技術。透過 Docker，他可以將需要的環境打包、建構出類似虛擬機器，但是更小、更彈性的可移植環境，在需要自動佈署的環境上，應該算是很實用的一種技術。（參考介紹、參考介紹）
不過由於工作的領域不同，所以 Heresy 其實之前都沒有去碰這一個技術；真的開始接觸到，是之前試著使用 Docker 來架設 GitLab Server 的時候開始的。
後來，Heresy 也很認真地開始搞整個 GitLab CI/CD 的架構，試著透過 GitLab 的系統來做一些程式開發的自動化建置、測試。最初，考慮到環境的熟系程度，Heresy 都是直接使用作業系統的 shell 來作為 gitlab-runner 的 executor。
Heresy 今年把新的 GitLab Server 架好後，就開始玩 CI/CD（Continuous Integration and Deployment）的功能、試著透過這個架構，來做一定程度的自動化了。
除了目前 C++ 專案的自動建置腳本已經算是完成了，其他一些特別的工作，也開始試著用 GitLab CI/CD 來玩，所以這段期間對這東西還算玩得滿認真的。
而從開始些 C++ 專案的跨平台建置開始，其實 Heresy 就覺得 GitLab CI/CD 的架構，有一點很討厭，就是他是基於「stage」來控制流程的，前面的 stage 沒有全部結束的話，後面的 stage 就不會進行。
所以如果整個 pipeline 有 build 和 test 兩個 stage 的情況下，就會變成要所有的 build 都完成，才能進行測試。
感謝網友提醒，根據官方《Cache vs artifacts》的說法，看來 Heresy 這邊把 build 階段產生的檔案透過 cache 傳遞到 test 階段，應該是嚴重的誤解／誤用了。 XD
之前在《GitLab 簡單的 C++ 專案腳本範例》和《GitLab 的 C++ CI/CD 腳本：使用 PowerShell》這兩篇文章，有分享了 Heresy 這邊目前 GitLab CI/CD 的腳本寫法了。
而當時也有提到，在 build 階段到 test 階段，Heresy 沒有玩出比較正規的檔案傳遞方法。
最近 Heresy 又開始測試這部分的東西。理論上，要在不同的 job 間傳遞檔案，是要透過在 .gitlab-ci.yml 裡面加上 cache（官網）來做。
在有加入 cache 的狀況下，GitLab Runner 會在 job 開始、透過 git 取得檔案後，就試著把 cahce 的檔案抓下來；而當腳本執行完後，則會再把 cache 指定的檔案打包，放到 Gitlab-runner 上。
Heresy 目前加上 cache 後的 .gitlab-ci.yml 大致上會像下面這樣：
之前已經在《GitLab 簡單的 C++ 專案腳本範例》這篇文章裡面，大概整理了一下 Heresy 這邊針對自己的 C++ 專案、撰寫出來的 GitLab CI 自動建置的腳本了。
不過，當時在 Windows 平台下，Heresy 是使用「Windows Batch」（CMD）這個 shell 來進行操作的。
但是，GitLab 官方其實有說，從 11.11 開始，就將「Windows Batch executor」設定為棄用（deprecated），並將於 13.0 時移除（預計時間是 2020/06/22）；而取而代之的，GitLab 將使用 PowerShell 來作為 Windows 上預設的 shell。（參考）
而這篇記錄，就是簡單地記錄一下 Heresy 把之前 cmd 的 script、改寫成 PowerShell 版本的紀錄。
之前寫過《Gitlab CI/CD 簡單介紹》，大概介紹過 GitLab CI/CD 的架構了，而 Heresy 這邊，其實也針對工作用的 C++ 專案，撰寫了對應的腳本了。
雖然實際上還是有點問題，不過目前看來運作得好像也還算正常，就來稍微分享一下吧～
首先，在系統的配置上，Heresy 這邊是準備了兩台 VM 作為 GitLab Runner，一台是 Windows 10、一台是 Ubuntu，分別處理 Windows 和 Linux 的環境。
而在腳本上，則是分成了分析、建置、測試三個階段：
