Continuous Integration opzetten

[kad-busses]

Momenteel worden de componenten handmatig gereleased, gebouwd, gepushed naar registry en gedeployed. Dit moet geautomatiseerd worden aan de hand van Github Actions. Toevoegen van CI voor linting, testing en releasing.

• registry-backend
• sync
• multichain-node
• registry-frontend
• central-viewer
• central-viewer-geoserver

Edit 2021-05-20:
De private dependencies van registry-frontend en central-viewer zijn inmiddels vervangen met open source alternatieven (kadaster-labs/sensrnet-registry-frontend#156 en kadaster-labs/sensrnet-central-viewer#23).

[kad-busses]

Github Actions fungeert als een buildserver, vergelijkbaar met Jenkins. We kunnen zelf triggers kiezen, bijvoorbeeld een push op master of het ontstaan van een nieuwe tag, waarbij de voorgedefinieerde jobs moeten worden uitgevoerd. Er zijn integraties beschikbaar voor docker en azure. Een combinatie hiervan kan ons een volledige CI/CD-straat leveren.

[kad-busses]

Binnen de repo's maken we gebruik van protected master branches om controle te houden over welke code gemerged wordt. Dat leent zich daardoor het beste als trigger om te gaan bouwen. De master branch is daardoor de meest recente release code.

Stappen

1. Updaten van de NPM versie
2. Bouwen van nieuwe Docker image
3. Pushen van de image naar de container registry (ACR)
4. Nieuwe versienummer in package(-lock).json opslaan in repo
5. Deployen van nieuwe image op cluster(s)

npm versie updaten

In Github Actions kan de npm package versie worden opgehoogd waar de release mee gemaakt wordt. Deze change moet vervolgens gecommit worden. Omdat de master branch protected is, kan Github Actions de aangepaste package.json niet committen op deze branch.

Wijzigingen van de release committen

Eén van de overwogen opties was om een aparte release branch aan te maken. Dan heb je echter het probleem dat deze code nog niet in master terecht komt. Daarvoor kan je uiteraard een nieuwe PR aanmaken, maar deze merge triggered vervolgens een nieuwe build en kom je in een lus terecht.

Een betere opties is daarom om in de repo's gebruik te maken van een extra development branch. Daar kunnen de features heen gemerged worden. Een merge van development naar master triggered dan een release. De door de release gewijzigde bestanden kunnen vervolgens weggeschreven worden op de development branch. Hiermee blijft de master een protected branch waar vanaf de releases worden gedaan en houden we de release tags bij. Enig nadeel is dat de meest recente tag op de development branch staat in plaats van de master branch.

Github Actions benodigdheden

Vereisten voor de Github Actions workflow is zijn:

1. Een AKS cluster met attached ACR
2. Managed identity voor cluster toegang
3. Github secrets: REGISTRY_USERNAME and REGISTRY_PASSWORD voor pushen naar ACR
4. Github secret: KUBE_CONFIG die de cluster info bevat van de clusters waarop gedeployed wordt

[marcvanandel]

In Jenkins hadden we een filter op de PRs die wel en niet door de build server zelf getriggered werden.

• Niet door de build server zelf => release
• Wel door de build server getriggered => deploy

Zouden we dat hier ook kunnen toepassen?

[kad-busses]

Niet 1 op 1. Standaard gebruikt Github Actions een aparte GH Actions user, welke updates op de repo kan doen. Het probleem is echter dat deze, net als reguliere gebruikers, niet op protected branches kan pushen.

Om toch naar de master branch te kunnen pushen, zodat geen extra handmatig PR nodig is, is een workaround nodig. Enige optie is hier om een Personal Access Token te gebruiken van een administrator, gezien administrators wél naar protected branches kunnen pushen. Dan zijn we echter de 'triggerer', GH Actions user dus, kwijt.

Genoemde scenario kunnen we alsnog bereiken aan de hand van commit messages en daar de acties op baseren. De GH Actions workflow kunnen we dan de repo laten updaten met bijv. de message "Release vX.X.X". Deze commit kan dan een deploy triggeren. Nadeel is dat de developers niet dit formaat als commit message kunnen gebruiken.

[kad-busses]

De workflow komt er dan ongeveer als volgt uit te zien:

on: push

jobs:
  build-job:
    runs-on: ubuntu-latest
    steps:
      - if: startsWith(github.event.commits[0].message, 'Release v') == false
        run: docker build .

[marcvanandel]

Backend: kadaster-labs/sensrnet-registry-backend#58

[kad-busses]

Voor de front-end moeten eerst de closed-source afhankelijkheden vervangen worden. Zie daarvoor kadaster-labs/sensrnet-registry-frontend#104

[kad-busses]

Voor de continue deployments heb ik een apart issue aangemaakt (#37)

[kad-busses]

Een CI workflow voor linting, testen en builden is nu actief op PRs en de main branch van de Node.js projecten: frontend, viewer, backend en sync. De CI geeft nu een melding als 1 van deze stappen faalt.

Een verdere workflow voor de het maken van Releases is actief op alle repo's. Hiermee kan handmatig een release worden gedaan, waarbij gekozen kan worden voor release volgens semver nummering: een patch, minor of major release.