Esplorare la promozione di origini interne
Il flusso di lavoro delle richieste pull basate su fork è diffuso nei progetti open source perché consente a chiunque di contribuire a un progetto.
Non è necessario essere un collaboratore esistente o l'accesso in scrittura a un progetto per offrire le modifiche.
Questo flusso di lavoro non è limitato all'open source: i fork consentono anche di supportare flussi di lavoro di origine interna dentro l'azienda.
Prima dei fork, era possibile contribuire a un progetto usando richieste pull.
Il flusso di lavoro è abbastanza semplice: eseguire il push di un nuovo ramo nel repository, aprire una richiesta pull per ottenere dal team una revisione del codice e far valutare ad Azure Repos i criteri del ramo.
È possibile fare clic su un pulsante per unire la richiesta pull in quello principale e distribuirla quando il codice viene approvato.
Questo flusso di lavoro è ideale per lavorare con il team sui progetti. Ma cosa succede se si nota un semplice bug in un progetto diverso all'interno dell'azienda e si vuole correggerlo autonomamente?
Cosa succede se si intende aggiungere una funzionalità a un progetto che si usa ma che è sviluppato da un altro team?
È qui che entrano in gioco i fork che sono al centro delle pratiche di origine interna.
Origine interna
L'origine interna, talvolta denominata "open source interna", offre tutti i vantaggi dello sviluppo di software open source all'interno del firewall.
Apre i processi di sviluppo software in modo che gli sviluppatori possano collaborare facilmente ai progetti dell'intera azienda.
Usa gli stessi processi diffusi in tutte le community di software open source.
Ma mantiene il codice sicuro e protetto all'interno dell'organizzazione.
Microsoft usa pesantemente l'approccio di origine interna.
Come parte degli sforzi per standardizzare un sistema di progettazione unica in tutta l'azienda, supportato da Azure Repos, Microsoft ha aperto il codice sorgente di tutti i nostri progetti a tutti gli utenti dell'azienda.
Prima del passaggio all'origine interna, Microsoft era "a compartimenti stagni": solo i tecnici che lavoravano su Windows potevano leggere il codice sorgente Windows.
Solo gli sviluppatori che lavoravano su Office potevano esaminare il codice sorgente Office.
Quindi, se un tecnico che lavorava su Visual Studio pensava di aver trovato un bug in Windows o Office – o voleva aggiungere una nuova funzionalità – non era possibile.
Ma utilizzando l'origine interna in tutta l'azienda, basata su Azure Repos, è facile creare un fork di un repository per contribuire.
In qualità di utente che apporta la modifica, non è necessario l'accesso in scrittura al repository originale, ma solo la possibilità di leggere e creare un fork.