Su AZ-400 il dominio Design and implement processes and communications non chiede di configurare un webhook, ma di rispondere a una domanda diversa: dato questo assetto di team e questi requisiti di audit, quale struttura di flusso e quale catena di link garantiscono che ogni riga di codice in produzione sia riconducibile a una decisione tracciata. Diamo per acquisiti i meccanismi di base e concentriamoci sulle decisioni di design e sui trade-off.

Struttura del flusso: GitHub Flow e i suoi limiti

GitHub Flow è un workflow leggero e branch-based: si crea un branch dal default branch, si committa, si apre una pull request per raccogliere feedback, si iterano le review, si fa merge sul default branch e si elimina il branch. Non è pensato solo per il codice: la documentazione lo presenta come applicabile a qualsiasi contenuto versionato, dalle policy ai documenti.

La decisione architetturale non è “usare o no le pull request”, ma quanto lunga può vivere una branch. GitHub Flow assume che il default branch sia sempre deployabile e che l’integrazione sia frequente: è la scelta naturale per un team in continuous delivery con un solo artefatto in produzione. Il trade-off emerge quando devi supportare più versioni contemporaneamente in manutenzione (software on-premises, firmware, release LTS): lì la topologia a solo default branch non basta e servono branch di release con cherry-pick controllati, pagando in complessità di merge e disciplina di hotfix.

Il secondo trade-off è la granularità del branch. Branch corte riducono i conflitti e accorciano il ciclo di feedback, ma spingono al merge di funzionalità incomplete: la contromisura sono i feature flag, che disaccoppiano il deploy dal release. Branch lunghe evitano il problema ma reintroducono il big-bang merge e allontanano il momento in cui la CI dice la verità sul codice.

Terzo punto: la pull request è il gate di qualità, non un adempimento. Sono le protezioni sul default branch (review obbligatorie, check di stato che devono passare, ownership del codice) a trasformare il flusso in un controllo effettivo; senza di esse GitHub Flow è solo una convenzione di naming.

Cicli di feedback: Issues, template e igiene delle notifiche

GitHub Issues è il canale di feedback interno ed esterno al team. La decisione di design rilevante è come strutturare l’input per renderlo azionabile senza triage manuale.

I template vivono nella directory nascosta .github/ISSUE_TEMPLATE sul default branch: quelli creati su altre branch non sono disponibili ai collaboratori. Esistono due forme con trade-off netti. I template Markdown (.md, con front matter name e about) sono testo guida: flessibili, ma il contributore può ignorarli. Gli issue form in YAML (.yml, con name e description) espongono campi di web form tipizzati e permettono di marcare gli input come obbligatori, convertendo poi la compilazione in un normale commento Markdown. Regola di design: usa gli issue form quando il costo del triage supera la frizione imposta a chi apre la issue, tipicamente per bug report che richiedono versione, ambiente e passi di riproduzione.

Sul lato notifiche il rischio è opposto: il rumore. GitHub sottoscrive automaticamente chi viene assegnato a una issue, chi apre una pull request, chi commenta un thread e chi viene menzionato con @. Le sottoscrizioni possono essere granulari, tra cui l’attività di un intero repository, l’attività CI dei workflow GitHub Actions e tipi di contenuto specifici (issue, pull request, release, security alert, discussion). La consegna avviene via inbox delle notifiche, email e app GitHub Mobile, anche in combinazione.

Il trade-off da governare è segnale contro copertura: sottoscrivere l’intero repository garantisce che nulla sfugga ma produce alert fatigue, e un team che ignora le notifiche non ha un ciclo di feedback, ha un log. Il design corretto instrada gli eventi ad alto valore (pipeline fallita sul default branch, security alert) su canali dedicati e lascia il resto alla sottoscrizione per partecipazione e menzione.

Integrazione Azure Boards e GitHub: la sintassi AB#

Quando il codice sta su GitHub e la pianificazione su Azure Boards, il ponte è l’app Azure Boards per GitHub, che si autentica e opera come applicazione e non come singolo individuo: sceglierla evita che l’integrazione si rompa quando quella persona lascia il team. Azure DevOps Services si integra sia con GitHub.com sia con GitHub Enterprise Server; Azure DevOps Server 2020 e versioni successive supportano solo GitHub Enterprise Server, e altri repository Git non sono supportati.

Il link si crea inserendo AB#{ID} nel messaggio di commit, nella descrizione di una pull request o nella descrizione di una issue. Questo è il dettaglio che l’esame ama: usare AB#ID in un commento o nel titolo di una pull request non crea il link.

La transizione di stato è la seconda leva. Azure Boards riconosce un nome di stato o di categoria e parole chiave come fix, fixes, fixed, applicandoli al riferimento AB# che segue. Con fix, fixes o fixed il work item passa al primo stato della categoria Resolved e, se il processo non ne definisce nessuno, al primo stato della categoria Completed; con un nome esplicito come Closed AB#1234 il sistema tenta lo stato specifico e, se non lo riconosce, ricade sulla categoria di workflow corrispondente. Due vincoli decisivi: le regole di transizione non si applicano se la pull request non viene mergiata nel default branch, e in una lista come Fixes AB#123, AB#124, AB#126 transita solo il primo work item. Per chiuderli tutti serve ripetere la parola chiave davanti a ciascuno.

Il vincolo di topologia: un repository GitHub va connesso a una sola organizzazione e un solo progetto Azure DevOps, perché connetterlo a progetti in organizzazioni diverse produce linking AB# inatteso. Azure DevOps Services supporta fino a 2.000 connessioni a repository GitHub per connessione.

Tracciabilita source, bug e quality fino alla build

La catena “end-to-end” è work item, branch, commit, pull request, build. I primi anelli si chiudono con AB# e con gli aggiornamenti automatici: una pull request nata da un branch collegato viene agganciata al work item, il merge commit risultante viene collegato dopo il merge, e alla cancellazione del branch il relativo link viene rimosso.

L’ultimo anello richiede una scelta esplicita. Nelle pipeline YAML l’opzione Automatically link new work items in this build genera i link Integrated in build nella sezione Development del work item, portando i repository GitHub alla stessa tracciabilità di Azure Repos. Vale la pena conoscere la logica di calcolo, perché spiega i falsi negativi: alla prima build vengono considerati tutti i work item collegati a branch, commit e pull request associati; nelle build successive viene calcolato il delta fra il commit corrente e quello dell’ultima build riuscita sullo stesso source branch. Cambiare branch di build o riscrivere la storia rompe la continuità del delta.

Sul fronte quality e bug restano due asimmetrie. La creazione automatica di un work item al fallimento della build (Create work item on failure) è supportata solo nelle pipeline Classic: in YAML va ottenuta con un’estensione del marketplace o via Azure CLI o REST API. E la ricerca ha un limite preciso: non puoi interrogare i work item per link ad artefatti GitHub, puoi solo filtrare su External Link Count > 0. Se serve reportistica fine sui link GitHub, la risposta non è una query di Boards.

Per la visibilità di stato restano due strumenti complementari: i badge di stato in Markdown nel README e i pull request insights nella sezione Development, che mostrano draft, review e check CI delle pull request collegate. Richiedono di accettare i permessi aggiornati di lettura e scrittura su Checks per l’app Azure Boards.

Trappole tipiche d’esame

  • “AB#123 scritto in un commento della pull request non collega il work item” - il link nasce solo da messaggio di commit, descrizione della pull request o della issue; non da commenti né dal titolo.
  • “Fixes AB#101, AB#102 chiude solo il primo work item” - comportamento previsto: ripetere la parola chiave davanti a ogni riferimento.
  • “Il team lavora su una release branch e le transizioni non avvengono” - le regole di transizione valgono solo al merge nel default branch.
  • “Serve tracciabilità dal work item alla build su repo GitHub con pipeline YAML” - abilitare Automatically link new work items in this build, non link manuali.
  • “Servono report sui work item con link a pull request GitHub” - non esiste query per link ad artefatti GitHub; al massimo External Link Count > 0, altrimenti serve l’API.
  • “L’integrazione si rompe quando l’amministratore lascia l’azienda” - usare l’app Azure Boards per GitHub, che opera come applicazione.
  • “I bug report arrivano senza versione e passi di riproduzione” - issue form YAML con campi obbligatori in .github/ISSUE_TEMPLATE sul default branch, non un template Markdown descrittivo.