La delivery del software è un momento molto particolare poichè dobbiamo prestare attenzione a cosa rilasciamo. Proprio per questo, è importante che impostiamo quante più branch policy possibili per automatizzare al massimo il processo e limitare i possibili danni che potremmo fare intervenendo in modo alternativo a quanto previsto.

Supponendo di dover lavorare con una branching strategy basata sullo standard GitFlow, per esempio, potrebbe venir comodo limitare gli accessi al branch principale solamente a pull request che arrivano dai branch di release. Poichè non esiste niente di built-in in GitHub, ci possiamo costruire un workflow custom.

name: Validate branch name

on:
  pull_request:
    branches:
    - main

jobs:
  validate-merge-ref:
    name: Validate merge ref on main
    runs-on: ubuntu-latest
      
    steps:
    - name: Validate head ref 
      if: ${{ !startsWith(github.event.pull_request.head.ref, 'release') }}
      run: exit 1

Il workflow di esempio viene eseguito sempre ad ogni creazione o update di una pull request che fa target al branch main, ovvero il principale di cui vogliamo tracciare le release fatte e pronte per la messa in produzione.

Tra gli step ne abbiamo solo uno, che viene eseguito solo nel caso in cui il branch da cui è stata originata la PR non sia release. In caso lo sia, lo step non viene eseguito e il workflow termina con successo senza aver eseguito di fatto niente. Al contrario, lo step lancia un exit code diverso da zero, che produce automaticamente un errore e fa terminare il processo.

Se uniamo questo workflow alle branch policy di GitHub, possiamo facilmente controllare tutte le pull request che vengono eseguite sul branch main e impedire che venga fatto il merge di codice che arriva da branch che non corrispondono al processo definito.