Che cos'è un flusso di lavoro basato su versioni?
In questo articolo viene descritto come creare un flusso di lavoro basato su versioni usando GitHub.
Che cos'è un flusso di lavoro basato su versioni?
Un flusso di lavoro basato su versioni è un insieme di modelli e criteri incentrato sul rilascio di software. Benché questo concetto possa sembrare un obiettivo ovvio per un team di sviluppo, il valore di questa prospettiva è molto confuso. In questa unità viene presentato il modo in cui vengono gestite tre diverse parti del ciclo di rilascio: gestione del progetto, selezione di una strategia di diramazione e rilascio ai clienti.
Pianificazione del lavoro con bacheche di progetto di GitHub
Dal punto di vista della pianificazione, un approccio incentrato sulle versioni significa che i problemi vengono divisi in iterazioni distinte che producono una nuova versione. Queste iterazioni vengono spesso denominate sprint e sono suddivise in periodi di tempo più o meno uguali per produrre modifiche incrementali. Gli altri team preferiscono riunire intere versioni finali in un'unica iterazione che può durare alcuni mesi o più a lungo. In GitHub queste iterazioni vengono gestite come progetti.
La caratteristica principale di un progetto è la sua bacheca. La bacheca è il piano di record centrale per l'iterazione e contiene tutte le schede che devono essere risolte. Una scheda può rappresentare un problema, una richiesta pull o anche solo una nota generica.
Per impostazione predefinita, ogni scheda inizia nella colonna To do (Da completare) e passa a In progress (In corso) dopo l'inizio del lavoro, per poi terminare con Done (Fine). È possibile personalizzare queste colonne, aggiungere altre colonne o applicare l'automazione allo spostamento delle schede e alle relative proprietà in base al processo del team.
Altre informazioni sulla gestione delle bacheche di progetto.
Lo stato di progetto della scheda è integrato nel repository. Ad esempio, il trascinamento di una scheda da To do (Da completare) a In progress (In corso) ne modifica lo stato e aggiorna l'indicatore visivo accanto al titolo del progetto. La sezione verde indica che la parte delle schede contrassegnata come Done (Fine), mentre il viola viene usato per le schede In progress (In corso). Lo spazio rimanente rappresenta la quantità di schede che devono ancora iniziare. Oltre a trascinare le schede nella bacheca, è possibile aggiornarle dalla rispettiva visualizzazione principale.
Quando si usa una bacheca del progetto, tutte le parti interessate hanno a disposizione un semplice metodo per identificare lo stato e la velocità di un progetto. È anche possibile creare bacheche con ambito limitato a singoli utenti o a una raccolta di repository di proprietà di un'organizzazione.
Altre informazioni sulla verifica dello stato del lavoro con bacheche di progetto.
Verifica di attività cardine specifiche
Per i team, o talvolta subset di team, GitHub offre la verifica con attività cardine.
Le attività cardine sono simili alla verifica del progetto in quanto l'enfasi viene posta sul completamento in ordine di priorità della gestione dei problemi e delle richieste pull. Tuttavia, mentre un progetto potrebbe essere incentrato sul processo del team, un'attività cardine è incentrata sul prodotto.
Altre informazioni sul verifica dello stato del lavoro con attività cardine.
Selezione di una strategia di diramazione
I repository in cui più sviluppatori lavorano in parallelo devono definire una strategia di diramazione appropriata. La definizione di un approccio unificato all'inizio del progetto elimina i motivi di confusione e di frustrazione con il crescere del team e della codebase.
Flusso di GitHub
Oltre a fornire una piattaforma per lo sviluppo di software basato sulla collaborazione, GitHub offre anche un flusso di lavoro prestabilito, progettato per ottimizzare l'uso delle diverse funzionalità. Benché GitHub supporti praticamente qualsiasi processo software, è consigliabile tenere conto del flusso di GitHub se il team non è ancora stabilito in un processo.
Uso di rami di lunga durata
Un ramo di lunga durata è un ramo Git che non viene mai eliminato. Alcuni team preferiscono evitarli completamente a favore di rami con funzionalità di breve durata e di correzione di bug. Per questi team, l'obiettivo di qualsiasi attività è quello di produrre una richiesta pull che riunisce il lavoro in main. Questo approccio può essere efficace per i progetti che non devono mai tornare indietro, ad esempio applicazioni Web proprietarie che non supportano mai una versione precedente.
Tuttavia, esistono alcuni scenari in cui un ramo di lunga durata soddisfa i migliori interessi di un team. Il caso più comune per un ramo di lunga durata è quando un prodotto ha più versioni che devono essere supportate per un periodo di tempo esteso. Quando un team deve pianificare questo impegno, il repository deve seguire una convenzione standard, ad esempio release-v1.0, release-v2.0 e così via. Questi rami devono anche essere contrassegnati come protetti in GitHub, in modo che l'accesso in scrittura sia controllato e che non possano essere eliminati accidentalmente.
I team devono comunque mantenere main come ramo radice ed eseguire il merge delle modifiche del ramo della versione upstream finché rientrano nel futuro del progetto. Al momento opportuno, release-v3.0 deve basarsi su main, in modo che l'attività di manutenzione per release-v2.0 non complichi il repository.
Manutenzione di rami di lunga durata
Si supponga che sia stato eseguito il merge di una correzione di bug nel ramo release-v2.0 e quindi di nuovo upstream in main. In seguito si è scoperto che questo bug era presente anche nel ramo release-v1.0 e la correzione avrebbe dovuto essere sottoposta a backporting per i clienti che usavano ancora tale versione. Qual è il modo migliore per eseguire il backport di questa correzione?
L'unione del ramo main in release-v1.0 non è un'opzione praticabile, perché include un numero significativo di commit che non è previsto facciano parte di questa versione. Per lo stesso motivo, la riassegnazione di release-v1.0 nel commit main corrente non è un'opzione fattibile.
Un'opzione alternativa consiste nel reimplementare manualmente la correzione nel ramo release-v1.0, ma questo approccio richiederebbe molto lavoro aggiuntivo e non verrebbe distribuito in modo appropriato in più versioni. Tuttavia, Git offre una soluzione automatica a questo problema grazie al comando cherry-pick.
Che cos'è il comando cherry-pick di Git?
git cherry-pick è un comando che consente di applicare commit specifici da un ramo a un altro. In pratica, esegue l'iterazione dei commit e li applica al ramo di destinazione come nuovi commit. Se necessario, gli sviluppatori possono eseguire il merge di tutti i conflitti prima di completare il backport.
Altre informazioni sul comando cherry-pick di Git.
Rilascio agli utenti
Quando la versione di un prodotto è pronta per essere rilasciata, GitHub semplifica il processo di creazione di pacchetti e notifica agli utenti.
La creazione di una versione è semplice come la compilazione di un modulo:
- Immettere un tag Git da applicare, che deve seguire Versionamento Semantico, ad esempio
v1.0.2. GitHub gestisce il processo di creazione del tag Git specificato. - Immettere un nome per la versione. Alcune procedure comuni:
- Usare un nome descrittivo
- Usare la versione Git
- Usare un riepilogo conciso di come è cambiata la versione rispetto alla precedente
- Usare un nome in codice o una frase casuale
- Fornire le note sulla versione. Questa attività può essere automatizzata con l'app Release Drafter, che analizza le modifiche rispetto alla versione precedente e include i titoli delle richieste pull associate.
- Se si vuole fornire file come parte della versione, ad esempio i programmi di installazione predefiniti, è possibile trascinarli e rilasciarli nel modulo. Non è necessario creare un pacchetto dell'origine, in quanto GitHub gestisce automaticamente questa operazione.
- Indicare se la versione è preliminare selezionando tale casella. Questa indicazione consente ai clienti di evitare le versioni non definitive se vogliono.
Una volta pubblicata una versione, tutti gli utenti che guardano il repository ricevono una notifica.
Altre informazioni sulle versioni GitHub.