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 都完成，才能進行測試。
<!–more–>
像上方右圖，就是 Heresy 這邊之前寫的腳本，分別有 Windows 與 Linux 的 build 和 test。理論上 Windows 建置完後，就可以直接進行 Windows 版的測試了；但是由於 GitLab CI/CD 是以 Stage 為單位來作流程控制，所以這邊就會出現「因為 Linux 版建置失敗、所以無法進行 Windows 版測試」的不合理的狀況…
而由於這是 GitLab CI/CD 在架構上的限制，所以並沒有比較好的解法…
不過，GitLab 官方也知道這個問題，所以在最新的 GitLab 12.2 中，引進了「Directed Acyclic Graphs (DAG)」的功能（官方說明），讓 pipeline 裡的 job 可以各自去設定他們的相依性、藉此來讓整個 pipeline 裡面的工作可以有各自的路線。
下面就是這個功能在運作時的官方示意圖：
這邊個人覺得最可惜的，是他目前畫出來的 pipeline 中，job 之間的連線也都無法表現出 DAG 的特性，這點也是比較可惜、讓使用者可能會混淆的部分了。
至於要怎麼使用呢？其實相當簡單，只要在 gitlab-ci.yml 中的 job、加上新的「needs」這項標籤（官方文件）就可以了。
像下面是 Heresy 這邊 C++ 專案目前的 pipeline 流程圖：
而下面則是 gitlab-ci.yml 簡化過的結果：
stages: - analysis - build - test DummyJob: stage: analysis cppcheck: stage: analysis build-windows: stage: build needs: [DummyJob] test-windows: stage: test needs: [build-windows] build-linux: stage: build needs: [DummyJob] test-linux: stage: test needs: [build-linux]
可以看到，「needs」的寫法是相當簡單的～
而由於 analysis 的階段其實不影響 build，所以為了讓後面的 build 不要被 analysis 卡住，所以 Heresy 又在這邊加了一個「DummyJob」，裡面什麼事都不做；而之後的「build-windows」和「build-linux」由於都只需要「DummyJob」，所以也就可以在 analysis 完成前、就開始建置了～
如果真的按照關連線來連接 job 的話，則會是下面的樣子：
透過這個 DAG 的功能，可以讓 GitLab CI/CD 的 stage / job 在編排上更為彈性，同時也可以讓 GitLab Runner 利用效率更高！在 Heresy 來看，算是相當實用的了。
不過由於這項功能還算是相當新的功能，在功能的完整性上也還不是很完善。除了前面講的圖畫的不夠好之外，目前 needs 只支援一個 job、也不支援沒有 job（支援的話可能就不用現在的 DummyJob 了）。
目前官方也列不少少其他的限制，就等之後 GitLab 再繼續把這項功能發展完善吧～