Strategie voor branching en merging

Probleem

In een GitOps-opzet met Ansible vereist het beheren van wijzigingen over meerdere omgevingen zoals ontwikkeling, staging en productie een gestructureerde aanpak om fouten te vermijden, testen te waarborgen en beveiliging te handhaven. Zonder duidelijke branchingbeleid lopen teams het risico om ongeteste code uit te rollen, conflicterende wijzigingen of ongeautoriseerde aanpassingen aan kritieke branches.

Context

GitOps-praktijken omvatten het gebruik van Git als de enige bron van waarheid voor infrastructuur- en applicatieconfiguraties. In projecten gebaseerd op Ansible betekent dit het opslaan van inventarissen, playbooks en variabelen in een Git-repository, in een zogenaamd Ansible-inventarisproject. Branches kunnen verschillende omgevingen vertegenwoordigen, waardoor wijzigingen via merge requests (MRs) kunnen worden gepromoot. Beschermde branches in tools zoals GitLab of GitHub dwingen reviews, goedkeuringen en CI/CD-pipelines af voordat merges plaatsvinden, zodat wijzigingen worden gecontroleerd en automatisch getest.

Oplossing

Implementeer een branchingstrategie die aansluit bij GitOps-principes, met behulp van omgevingsspecifieke omgevings-branches en merge requests voor promoties. Dwing beleid af met beschermde branches om controle en traceerbaarheid te behouden.

Volg deze richtlijnen:

1. Definieer Kernbranches: Creëer permanente branches voor elke omgeving. Dit zijn zogenaamde omgevings-branches. Het is belangrijk dat ze overeenkomen met een omgeving bestaande uit hosts die deel uitmaken van dezelfde Ansible-omgevingsgroep.

   • master: Dient als de stabiele, langetermijnbranch die de laatste productiestatus weergeeft na succesvolle promoties.
   • development: Voor lopende ontwikkeling en featurewerk.
   • staging: Voor het testen van wijzigingen voordat ze naar productie gaan.
   • production: Vertegenwoordigt de live productieomgeving; merge alleen vanuit staging na goedkeuringen.

2. Branchingbeleid:

   • Featurebranches: Creëer kortlevende branches vanuit development voor nieuwe features of bugfixes (bijv. feature/add-new-playbook).
   • Hotfixbranches: Voor urgente productiefixes, branch direct vanuit production (bijv. hotfix/issue-12345).
   • Vermijd directe commits naar omgevings-branches; gebruik altijd MRs voor wijzigingen.

3. Mergingworkflow:

   • Ontwikkel en test in development.
   • Merge van development naar staging via MR voor integratietesten.
   • Merge van staging naar production via MR na goedkeuringen en succesvolle CI/CD-runs.
   • Merge tenslotte production terug naar master om deze up-to-date te houden.
   • Voor hotfixes: Pas eerst toe op production via MR, en backport vervolgens naar andere branches.

4. Beschermde Branches:

   • Configureer branchbescherming voor alle omgevings-branches en voor master in je Git-platform (bijv. GitLab):
     • Vereis MR-goedkeuringen (bijv. minstens 2 reviewers).
     • Dwing succesvolle CI/CD-pipelines af voordat er gemerged wordt.
     • Beperk wie kan pushen of mergen (bijv. alleen admins voor production).
     • Voorkom force pushes en branchverwijdering.

5. Integratie van Automatisering:

   • Gebruik GitLab CI/CD of vergelijkbaar om Ansible-playbooks te triggeren bij merges, waarbij wijzigingen worden uitgerold naar de corresponderende omgeving. Typisch wordt AAP gebruikt; soms, als AAP niet wordt gebruikt, kan GitLab CI/CD worden ingezet.
   • Tag releases (bijv. semantic versioning) bij merges om versies te tracken.

Voordelen

• Consistentie en Veiligheid: Vermindert uitrolrisico’s door reviews en geautomatiseerde testen af te dwingen.
• Traceerbaarheid: MRs bieden een audittrail van wijzigingen en goedkeuringen.
• Schaalbaarheid: Ondersteunt teamcollaboratie zonder werk te overschrijven.
• Gemakkelijke Rollback: Omgevings-branches maken snelle revert mogelijk bij problemen.

Alternatieven

Hoewel Git Flow of GitHub Flow gebruikelijk zijn, passen ze mogelijk niet perfect bij de op omgeving gebaseerde promoties van GitOps. Een eenvoudigere trunk-based development kan werken voor kleinere teams, maar mist de gefaseerde promotie die nodig is voor gereguleerde omgevingen; de beschreven strategie is voorkeur voor Ansible GitOps-opzetten die duidelijke scheiding vereisen.

Voorbeelden en Implementatie

In een typisch Ansible GitOps-project structureer je je repository met branches die omgevingen vertegenwoordigen. Gebruik merge requests om wijzigingen te promoten, waardoor CI/CD-pipelines worden getriggerd die Ansible-playbooks uitvoeren voor uitrol.

Hier is een voorbeeld van een Git-workflow gevisualiseerd met Mermaid:

gitGraph
    commit id: "Initial commit"

    branch development
    checkout development

    branch staging
    checkout staging

    branch production
    checkout production

    checkout development
    commit
    commit
    commit id: " " tag: "1.0.0"
    checkout staging
    merge development tag: "1.0.0"
    checkout production
    merge staging tag: "1.0.0"
    commit id: "Production release 1.0.0"

    checkout main
    merge production tag: "1.0.0"

    checkout production
    branch hotfix-12345-fix-something
    commit id: "Hotfix applied" tag: "1.0.1-hotfix-issue-12345"

    checkout main
    merge hotfix-12345-fix-something  tag: "1.0.1-hotfix-issue-12345"

    checkout development
    merge hotfix-12345-fix-something tag: "1.0.1-hotfix-issue-12345"

    checkout staging
    merge hotfix-12345-fix-something tag: "1.0.1-hotfix-issue-12345"

Deze diagram illustreert:

• Initiële opzet van branches.
• Ontwikkelwerk gemerged naar staging, dan productie.
• Een hotfix toegepast op productie en gebackport naar andere branches.
• Finale merge naar master voor een stabiel record.

Aanvullende Informatie

• Ansible-inventarisproject: Een gestructureerde verzameling bestanden die worden gebruikt voor het beheren van hosts en configuraties. Het omvat doorgaans inventarisbestanden, playbooks, hostconfiguraties, groepsvariabelen en Ansible Vault-bestanden.