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. Anche se questa nozione potrebbe sembrare un obiettivo ovvio per un team di sviluppo, il valore di questa prospettiva è più sfumato. In questa unità viene illustrato come guida tre parti diverse 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 di queste schede e alle relative proprietà per adattarsi 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 A fare a 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 intorno alla lavagna, è possibile aggiornarle dalla loro vista principale.
Quando si usa una scheda di progetto, tutti gli stakeholder hanno un modo semplice per comprendere 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 al rilevamento del progetto, in quanto è presente un'enfasi sul completamento con priorità dei problemi e delle richieste pull. Tuttavia, dove 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 risoluzione di un approccio unificato all'inizio del progetto consente di risparmiare confusione e frustrazione quando il team e la scalabilità 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à. Anche se GitHub può lavorare praticamente con qualsiasi processo di sviluppo software, è consigliabile prendere in considerazione il flusso di GitHub se il team non è ancora stato 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 hanno mai la necessità di esaminare indietro, ad esempio applicazioni Web di prima parte che non supportano 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 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. Successivamente è stato scoperto che questo bug esisteva anche nel release-v1.0 ramo e la correzione doveva essere sottoposto a backporting per i clienti che usano ancora tale versione. Qual è il modo migliore per eseguire il backport di questa correzione?
L'unione del ramo verso release-v1.0 il main basso in non sarebbe un'opzione fattibile, perché conterrà un numero significativo di commit che non erano destinati a far parte di tale versione. Per lo stesso motivo, la ribasazione release-v1.0 sul commit corrente main non sarebbe un'opzione.
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 sono:
- Usare un nome descrittivo
- Usare la versione Git
- Usare un riepilogo conciso del modo in cui la versione è cambiata rispetto a quella precedente
- Usare un nome in codice o una frase casuale
- Fornire le note sulla versione. È possibile automatizzare questa attività con l'app Release Drafter, che analizza le modifiche rispetto alla versione precedente e include i titoli delle richieste pull associati.
- Se si desidera 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.