CINQby Victor Louisa
Sinds 13 november 2019 is GitHub Actions officieel beschikbaar, de nieuwe CI/CD tool van Github. Nu bijna een half jaar verder, ben ik benieuwd hoe dicht Github Actions naar Azure Pipelines is gegroeid qua functionaliteiten maar ook in hoeverre Github Actions al Azure Pipelines kan vervangen. In dit blog zet ik de belangrijkste verschillen op een rij.
Zowel een Github Action workflow als een Azure Pipeline is een configureerbaar geautomatiseerd proces dat bestaat uit één of meerdere "Jobs". Met dit proces bepaal je de CI/CD flow.
In beide gevallen word de YAML syntax gebruikt. Dit word vaak gebruikt voor "Configuration as Code". In dit bestand bepaal je de configuratie van de workflow/pipeline. De locaties van deze bestanden verschilt per oplossing. Bij Azure Pipelines zet je het YAML bestand azure-pipelines.yml in de root folder van het project. Bij GitHub Actions komt deze in de folder /.github/worksflows/<workflownaam>.yml. De YAML bestanden in deze folder worden automatisch opgepakt. Je kan zowel de .yaml of .yml als bestandsextensie gebruiken.
Wil je meer informatie over YAML zie: Learn YAML in five minutes.
Github Actions en Azure pipelines gebruiken voor vergelijkbare stappen soms verschillende benamingen, hieronder een opsomming van de verschillen. Github Actions wordt steeds als eerst genoemd en Azure Pipelines als tweede.
Een event / trigger is een activiteit welke de Workflow / Pipeline triggert.
Workflows kunnen net als Pipelines getriggerd worden door het pushen van commits of tags naar specifieke branches in de gekoppelde repository. Maar ook door Pull requests of een scheduled trigger. Naast deze standaard triggers bied Workflows nog een groot aantal activiteiten binnen Github welke de workflow kunnen triggeren.
Kijk voor een lijst van alle Workflow en Pipeline triggers op Workflow Triggers en Pipeline Triggers.
Azure Pipeline ``stages`` zijn bedoelt om de activiteiten van de pipeline in fases te verdelen. Met gebruik van ``stages`` krijg je de mogelijkheid om de pipeline te pauzeren voor een handmatige check. Bijvoorbeeld wanneer een manager de release van de staging moet goedkeuren voordat deze door mag naar productie.
Github Actions heeft deze mogelijkheid niet.
Zowel Workflows als Pipelines bestaan uit ``jobs``. Een ``job`` bestaat uit één of meerdere ``steps``.
Een ``step`` kan bestaan uit een inline-script of een pre-packaged script. binnen Azure Pipelines ook wel een `task` genoemd. Een pre-packaged script is een `action` in Github Actions.
Een ``action`` of een ``task`` is een vooraf gemaakt script die je aan kan roepen in meerdere Pipelines of Workflows. Zowel Github Actions als Azure Pipelines bied built-in en custom ``actions``/``tasks``.
Het idee achter een custom ``action``/``task`` is het beheer van terug kerende activiteiten te versimpelen. Als je bijv. 10 Workflows of Pipelines hebt met een inline-script waar een aanpassing in nodig is. Zul je al die 10 Workflows/Pipelines moeten wijzigen. Met een ``action``/``task`` hoef je alleen de ``action`` of de ``task`` te wijzigen. De aanpassing is gelijk beschikbaar de eerst volgende keer dat de Pipelines draaien. Hierdoor hoef je niet meer al je Pipelines te wijzigen.
Pipeline ``Tasks`` zijn beschikbaar in de Visual Studio Marketplace. Maar er is ook de mogelijkheid om ze zelf te schrijven.
Community ``Actions`` zijn beschikbaar via de Github Marketplace. Ook ``Actions`` kan je zelf schrijven.
In Github Actions worden ``jobs`` toegewezen aan een ``virtual environment``. Dit kan zowel een Github-hosted of een Self-hosted runner zijn. Je hebt de keuze uit een Windows, Linux of een MacOS enviroment.
Github self-hosted runners zijn nog niet zo heel lang beschikbaar. De belangrijkste verschillen tussen hosted en Github-hosted runners zijn:
Github-Hosted runners bieden een simpelere en makkelijkere manier voor het draaien van workflows. Terwijl self-hosted runners meer configuratie mogelijkheden bieden voor specifieke benodigdheden binnen een workflow.
In Azure Pipelines worden ``jobs`` toegewezen aan ``agent pools``. Een `agent pool` is een groep van gelijke ``agents``. Een ``agent`` kan zowel hosted zijn of self-hosted. Hier heb je dezelfde opties als in Github, Windows, Linux of MacOS.
Als voorbeeld heb ik een simpele Angular app build pipeline gemaakt voor zowel Github Actions als Azure Pipelines binnen dezelfde repository zodat deze tegelijkertijd triggeren. [^1] Omdat Github Actions nog geen stages ondersteunt heb ik hier geen gebruik van gemaakt. Hierdoor zijn de YAML bestanden makkelijk te vergelijken.
Het resultaat van de bovenstaande Github Actions Workflow:
Het resultaat van de bovenstaande Azure Pipeline:
Github Actions bied deze mogelijkheid niet.
Om eerlijk te zijn is het antwoord afhankelijk van de functionele eisen. Hoe complex je Workflow/Pipeline moet worden en of je afhankelijk bent van handmatige goedkeuringen van bijv. een manager. Dit verschilt natuurlijk per project.
Als je nog geen Azure Pipelines gebruikt maar wel al Github gebruikt als code repository, en je hebt geen manual approvals nodig, dan is Github Actions de juiste keuze om mee te beginnen.
Mocht je wel al gebruik maken van Azure Pipelines i.c.m. Github Repositories dan zou je bijv. je code kwaliteit checks naar Github Actions kunnen verplaatsen die dan weer je Azure Pipeline triggert wanneer de code voldoet aan alle voorwaarden.
Github Actions is de afgelopen maanden hard gegroeid, en is naast Azure Pipelines een mooie toevoeging aan de bestaande CI/CD tooling. Hou er rekening mee dat er nog vol aan Github Actions ontwikkeld wordt, dit kan betekenen dat de huidige "tekortkomingen" er over een paar maanden niet meer zijn.
Heb je vragen of opmerkingen? Laat het gerust weten!