Nadat Microsoft in 2018 GitHub heeft overgenomen was het even afwachten welke in richting GitHub zou bewegen. Zou het een separate merknaam blijven of zou het geassimileerd worden binnen de bestaande Microsoft portefeuille? Nu na 3 jaar is het veilig om te zeggen dat GitHub als merk blijft bestaan. Vrij logische keuze omdat Microsoft welliswaar zijn eigen tegenhanger heeft met Azure DevOps maar het marktaandeel van GitHub is vele malen groter. Zeker als we sec kijken naar de source control mogelijkheden. (77% voor github vs 6% voor DevOps volgens een onderzoek van JetBrains: https://www.jetbrains.com/lp/devecosystem-2020/team-tools/)

Beide services bieden veel meer dan alleen source control en hier zien we ook de verschillen. Eén van de dingen die een tijdje terug zijn geintroduceerd in GitHub zijn de CI/CD mogelijkheden in GitHub Actions. Van oudsher had Microsoft hier al veel features voor in Azure DevOps en zijn voorganger TFS. We zien hier dat GitHub meer naar Azure DevOps aan het toebewegen is. Dus reden om eens kijken naar de verschillen en eventuele overlap van mogelijkheden.

Build pipelines Classic vs Modern


Zoals eerder aangegeven heeft Azure DevOps en zijn voorganger TFS al tijden mogelijkheden tot het opzetten van een CI/CD pipeline. Hier zijn grofweg 2 verschillende manieren. De inmiddels wat verouderde manier van de classic pipeline waar men een grafische interface de build en release pipeline in elkaar kan klikken.


De grafische terugkoppeling is waardevol, maar er is er één groot nadeel. Deze pipeline leeft alleen in Azure DevOps en bestaat niet uit code welke in de Git repo zit. Hierdoor is het lastig om bepaalde veranderingen in de build/release pipeline af te stemmen met de code. Zo kun bijvoorbeeld een extra project toevoegen welke je apart wilt compileren binnen dezelfde build/release pipeline. Dit doe in een feature branch in je git repo. Hiervoor moet je de pipeline aanpassen en tegelijkertijd ook je code. Maar misschien is je code nog niet klaar en wil in de tussentijd ook andere branches kunnen bouwen. Dan ontstaat er een probleem.


De oplossing voor dit soort problemen is het opzetten van een build/release pipeline in code en deze op te nemen in je git repo. Dan is de koppeling tussen je code en pipeline altijd 1 op 1. Dit is in Azure DevOps al enige tijd geleden introduceert met de zogenaamde moderne yaml pipelines. GitHub actions gebruikt al direct vanaf de start yaml als enige manier van opzetten van pipelines.  Voor dit vergelijk gaan we dan ook alleen kijken naar de yaml pipelines en laten de classic pipelines buiten beschouwing.

Overeenkomsten & Verschillen

Yaml scripts

Op het eerste gezicht lijken de yaml scripts van Azure DevOps pipelines en GitHub actions sterk op elkaar. Niet zo vreemd aangezien ze van dezelfde organisatie afkomstig zijn. Zo worden beide pipelines gestart middels triggers. Ze kunnen beide reageren op push events op verschillende branches en kunnen beide onderscheid maken op tags. Naast deze triggers kan men GitHub Actions pipelines starten op basis van GitHub events, dit zijn er legio en kan men b.v. een pipeline starten op basis een issue-comment – created of deleted event. Dit is niet mogelijk in Azure DevOps.  Beide oplossingen bestaan uit 1 of meerdere jobs, met daarin weer steps en tasks.  De notatie verschilt wel iets maar er zijn meer overeenkomsten dan verschillen. Er is ook documentatie beschikbaar om te migreren: https://docs.github.com/en/actions/learn-github-actions/migrating-from-azure-pipelines-to-github-actions

Agents

Naast de overeenkomsten in de syntax van yaml zijn de functionaliteit ook grotendeels overeenkomstig. Zo bieden beide platformen de mogelijkheid tot het runnen van script in een gehoste omgeving en met verschillende operating systemen zoals Linux, Windows  of MacOs. Daarnaast ook mogelijkheden om je eigen agents hiervoor te gebruiken. Het is wel zo dat Azure DevOps een eigen agents kan selecteren op basis van capabilities. Deze capabilities zijn name-value pairs die beschrijven wat een bepaalde agent kan. Zo staat daar b.v. het type van operating system en versie van de geïnstalleerde software in. Builds in Azure DevOps kunnen op basis van deze capabilities een keuze maken van beschikbare agents. In GitHub actions gaat dit op basis van labels die men als gebruiker zelf moet administreren. Dit is iets meer werk maar uiteindelijk kun je hetzelfde bereiken.

Security tools integratie

GitHub Actions heeft standaard features die een security scan op je code uitvoeren met een SAST oplossing (static application security testing). Dit is een native feature van GitHub actions en je hoeft hier geen extra  3th party tooling voor te gebruiken.  Dit kan ook in Azure DevOps maar dan moet men wel altijd gebruik maken van 3th party tooling. Daarnaast heeft GitHub Actions directe integratie met Dependabot zodat er geautomatiseerd pull requests worden aangemaakt indien een 3th party library een update heeft. Dit zijn belangrijke features voor je security beleid. Dit kan ook in Azure DevOps maar hier moet men wel zelf actie voor ondernemen.

Beschikbare standaard tasks

In Azure DevOps en GitHub Actions zijn veel verschillende standaard taken om de resultaten van de build te releasen naar veel verschillende omgevingen. Je kunt hier denken aan aan releases naar AWS, Azure, Google Cloud e.d. GitHub Actions hebben inmiddels bijna 9000 taken in marketplace staan, dit is aanzienlijk meer dan Azure DevOps (+/- 1200). Maar de belangrijkste en meest gebruikte taken zijn bij beide te vinden en zou in 99% van de gevallen voldoende moeten zijn.

Environments

Azure DevOps kent een tijdje begrippen als Environments, Stages & Templates. Hiermee is het mogelijk om per omgeving (Development, Test, Acceptance, Production) bepaalde approvals te zetten.  Je kunt hiermee bijvoorbeeld aangeven dat een acceptatie tester de release moet goedkeuren voor een release naar productie. Dit was iets was GitHub actions nog niet ondersteunde maar recent zit een soortgelijke functionaliteit ook in GitHub actions. (zie : https://docs.github.com/en/actions/reference/environments ) Deze functionaliteit is wel alleen beschikbaar in GitHub Enterprise.

Agile workflow management

Naast de build en release features biedt Azure DevOps meer functionaliteiten voor het begeleiden van je agile workflow. Denk hier aan mogelijkheden voor het maken van boards, backlogs, sprints e.d. Dit is functionaliteit die men niet in GitHub actions kan vinden maar waarvoor men dan afhankelijk is van andere tooling (b.v. Jira)

Conclusie

Beide zeer mooie en uitgebreide producten en er zijn meer overeenkomsten dan verschillen. Dus eigenlijk is keuze voor één van deze twee producten prima.  Mocht je keuze moeten maken dan is deze sterk afhankelijk van het ecosysteem waar je organisatie reeds gebruik van maakt. Zit je al in de Microsoft hoek of  wil je één product waar je hele ontwikkelproces in kunt beheren dan ligt de keuze voor Azure DevOps voor de hand. Ben je hier nog vrij om keuzes te maken of gebruik je b.v. Jira voor management van je agile workflow dan ligt dit minder voor de hand. De features die GitHub actions biedt voor integratie met security scan tooling is daar wel een sterk argument. Daarnaast lijkt GitHub actions meer momentum te hebben dan Azure DevOps en de nieuwe features volgen elkaar snel op. Dus in deze geen foute keuzes hooguit een keuze die beter aansluit bij de huidige werkwijze.

Auteur: Patrick Bes © 2021 Bergler Competence Center[heading]Lees ook…[/heading][recent_posts style=”list” columns=”1″ cat=”weblog”][/vc_column][/vc_row]