Die YAML-Konfigurationen für CI/CD-Pipelines sind selbst für kleine Projekte oft durch wiederholte Steps geprägt. Meist sind diese Steps für alle Umgebungen gleich oder enthalten lediglich minimale Änderungen. Um diesen Misstand zu beseitigen, können sogenannte Anchors verwendet werden. Dies wird in diesem Artikel am Beispiel von Bitbucket Pipelines demonstriert, lässt sich aber problemlos auch auf andere konfigurationsbasierte Pipelines - wie etwa die von GitLab - anwenden.

In einem üblichen JavaScript-Projekt könnte eine Pipeline mit Installations-, Test- und Build-Step wie folgt aussehen:

1image: node:latest
2
3pipelines:
4  develop:
5    - step:
6        name: Install
7        caches:
8          - node
9        script:
10          - npm i
11    - step:
12        name: Test
13        caches:
14          - node
15        script:
16          - npm test
17  master:
18    - step:
19        name: Install
20        caches:
21          - node
22        script:
23          - npm i
24    - step:
25        name: Test
26        caches:
27          - node
28        script:
29          - npm test
30    - step:
31        name: Build
32        caches:
33          - node
34        script:
35          - npm run build

Hier sieht man schnell das Optimierungspotential. Master und Develop-Branch teilen sich identische Steps. Mittels Anchors (&Anchor) können wir diese Steps ein Mal definieren und dann in beiden Steps ausgeben (*Referenz). Dieses würde in obigem Beispiel wie folgt aussehen:

1image: node:latest
2
3definitions:
4  steps:
5    - step: &Install
6        name: Install
7        caches:
8          - node
9        script:
10          - npm i
11    - step: &Test
12        name: Test
13        caches:
14          - node
15        script:
16          - npm run build
17
18pipelines:
19  develop:
20    - step: *Install
21    - step: *Test
22  master:
23    - step: *Install
24    - step: *Test
25    - step:
26        name: Build
27        caches:
28          - node
29        script:
30          - npm run build

Wie man sehen kann, wurde ein definitions Map hinzugefügt. Hier werden alle Anchors gehalten. Dies ist eine Bitbucket-Spezialität, für Anchors im generellen tut das aber nichts zur Sache. Definiert man einen Anchor (z.B. &Install) wird dieser Konfigurationsblock verfügbar gemacht, sobald man auf ihn referenziert (z.B. mit *Install).

Möchten wir nun beispielsweise auf mehreren Branches den selben Step ausführen, ihn jedoch leicht verändern, kann man dies wie folgt tun:

1image: node:latest
2
3definitions:
4  steps:
5    - step: &Install
6        name: Install
7        caches:
8          - node
9        script:
10          - npm i
11
12pipelines:
13  develop:
14    - step: *Install
15  master:
16    - step: 
17        <<: *Install
18        name: Install for Master

Wie man sieht, kann man mit dem << Operator Konfigurationen übernehmen und im Anschluss Werte von bestimmten Keys überschreiben.

Wer bereits an Konfigurationen für viele Umgebungen gearbeitet hat, weiß, dass leicht Fehler passieren, wenn man an vielen Stellen den gleichen Step bearbeiten muss. Mittels YAML-Anchors können Konfigurationen übersichtlicher gestaltet und vor allem Fehler vermieden werden.