這篇算是 Heresy 這邊透過 Docker 來架設 GitLab server 的一些後續，真要說的話，應該是之前《GitLab 升級到 13 的筆記》的延伸。
GitLab 在 13.0 的時候，把「Design Management」（官方文件）開放給免費的使用者使用了。這項功能的目的，主要應該就是讓使用者可以在 issue 中上傳圖檔，方便討論。
不過，對 Heresy 這種是從 GitLab 11 升級上來的人來說，這項功能預設是不能用的。而且還會在 issue 那邊顯示警告，看起來滿煩的。 XD
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 了。
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 的環境。
而在腳本上，則是分成了分析、建置、測試三個階段：
今年初，Heresy 算是終於把工作地方的 GitLab 重新架設起來了。而後來好一段時間，Heresy 則都是在研究他的 CI/CD（Continuous Integration and Deployment）到底該怎麼做，目前也算終於弄到可以動了，所以就在這邊紀錄一下吧～
不過，這篇主要是先就 Heresy 理解的概念來寫，也希望沒有理解錯誤就是了。
首先，Gitlab 的 CI/CD（官網）做的事情，實際上就是讓 Gitlab 系統，可以在特定的時候（通常是 push、merge、或是自己排程），根據所撰寫的腳本，去進行程式碼的自動化建置、測試、甚至佈署。
下面的圖，就是官方提供的 GitLab CI/CD 的示意流程圖。
之前在研究切割 Git Repository 的時候，曾經寫了一篇《分割 Git Repository》做紀錄，不過最近要再做處理的時候，才發現當時紀錄的方法，比較接近使用「filter-branch」這個指令來硬上；實際上 Git 本身還有提供其他的方法，可以更直覺地把 Repository 的一部分、切割出來成為一個獨立的 Repository。
這樣的功能，在 Git 裡面是所謂的 subtree。
如果要針對現有的 respository 做切割的話，基本上就是要使用 git subtree split 這個指令；例如：
git subtree split -P ModuleAPath -b "ModuleA"
上面的 git 指令的效果，就是建立出一個新的新的分支（branch）「ModuleA」，裡面只有「ModuleAPath」這個資料夾下的東西而已。
Heresy's Space 