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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Filtrare e rimuovere gli elementi dalla cache del browser tramite le API JavaScript
Creare gruppi di client per Event Grid MQTT
Determinare lo stato di un pod in Kubernetes
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Generare file PDF da Blazor WebAssembly con iText
Generare token per autenicarsi sulle API di GitHub
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Hosting di componenti WebAssembly in un'applicazione Blazor static
Load test di ASP.NET Core con k6
Miglioramenti nell'accessibilità con Angular CDK
Code scanning e advanced security con Azure DevOps
Utilizzare Tailwind CSS all'interno di React: primi componenti