Tieni i rami accumulati

Question

Tieni i rami accumulati

#1 da (22 voti)
#2 da (4 voti)
#3 da (3 voti)
#4 da (2 voti)
#5 da (2 voti)
#6 da (0 voti)
#7 da (0 voti)
#8 da (-2 voti)

19

Stiamo iniziando a imbattersi in un problema man mano che diventiamo più grandi, in cui le funzionalità lo rendono in fase di test, ma quando tutto viene testato e approvato, le nuove funzionalità sono in fase di staging per il test.

Questo sta creando un ambiente in cui non possiamo quasi mai spingere alla produzione perché abbiamo una combinazione di funzionalità testate e non testate. Sono sicuro che questo è un problema comune, ma non ho ancora trovato buone risorse per noi.

Alcuni dettagli:

GIT su BitBucket
Jenkins per la distribuzione con script in Azure

Quello che spero è un modo per isolare le caratteristiche mentre si muovono attraverso gli ambienti e solo spingere ciò che è pronto a fare.

git branching continuous-integration devops

posta Wesley 21.11.2016 - 18:30

fonte

8 risposte

4

Ecco un'idea, Smetti di usare i rami di rilascio. Invece, inizia a costruire in opzioni di attivazione e gestirlo tramite configurazione. In questo modo, stai sempre fondendo i branch delle funzionalità in master e non ci dovrebbe mai essere una domanda su quale versione è in testing o prod. Se hai una domanda su quali funzionalità / implementazioni sono attive in un ambiente, basta controllare il file di configurazione.

risposta data 23.11.2016 - 03:28

fonte

3

Questa dovrebbe essere una semplice questione di coordinamento tra test e produzione. Se stai utilizzando le branch di funzionalità in Git, semplicemente smetti di spingere i branch feature completati a Test durante un ciclo di test e riprendi quando il test è completo.

Se è necessario un controllo migliore di questo, separare Test in un server di sviluppo e un server di test di accettazione e coordinare i rami che verranno inviati al server di test di accettazione con il team di test. Qualcuno può quindi essere responsabile del lancio della distribuzione finale da Acceptance Test a Production.

risposta data 21.11.2016 - 18:38

fonte

2

Il lavoro si accumula

Questo è un problema universale nella mia esperienza. Lo indirizzo con:

strong gestione delle versioni del proprietario del prodotto
Verifica che i rami vengano eliminati quando vengono uniti
Limita lavori in corso (con limiti di colonna in Jira)
Revisione trimestrale dei vecchi ticket che languiscono, sia bug che funzionalità
Retrospettive per discutere i componenti del problema
Costante incoraggiamento per le revisioni del codice di tutti
Accoppiamento delle opportunità per affrontare ticket e problemi di vecchia data
Riunioni trimestrali per rivedere e pulire i vecchi biglietti
Approccio di gruppo per ottenere div, prodotto e QA / QE che lavorano strettamente insieme
Buoni rapporti e strumenti per creare nuove funzionalità del prodotto e il backlog ovvio
Rivedi le sessioni per passare attraverso i vecchi rami ed eliminarli

risposta data 22.11.2016 - 15:27

fonte

2

Filiali

Hai bisogno di alcuni rami per controllare quel processo:

funzione : questi rami nascono dal master. Utilizzare alcune applicazioni di gestione dei progetti per identificare ciascun ramo di funzionalità con alcune attività. Ad esempio, se utilizzi TRAC, finirai se rami come: 1234-user-crud , 1235-bug-delete-catalog , ecc. Identifica anche il tuo commit con il numero dell'attività, questo ti aiuterà molto quando hai problemi con l'unione (lo farai) .
test : tutti i rami delle funzionalità completati verranno uniti al ramo di test. tu non unisci mai il ramo di prova in qualche ramo di funzionalità , perché non vuoi il codice da altre funzionalità che non sono nella produzione (master). Lo stesso vale per il ramo release .

release : quando decidi quali funzionalità testate possono essere presenti nella produzione, unisci questi rami (di nuovo ...) in questo ramo. È necessario testare nuovamente tutte le funzionalità, perché questa unione può portare nuovi problemi. Una volta che la release è stata testata e completata, unisci questo ramo al master e crea un tag sul master per la versione.

master : contiene solo il codice di produzione.

Vedi il flusso git:

|FEAT_2| | .---C06<-------.---------. / \ \ / |FEAT_1| \ \ / | \ \ / .--C07<--.--------\---------\---------. / / \ \ |TEST| \ \ / / \ \ | \ \ / / .-----'--C09<--'--C10 \ \ |RELEASE| / / / \ \ | <v4.6.0> / / / .----'--C11<---'--C12<--. | / / / / \ C01<--C02<--C04<--´----´--------´-----------------------´---------------------------'--C13 | | | <v4.5.0> <v4.6.1> |MASTER| | <v4.7.0>

Ambienti

Molto semplice:

test : questo ambiente utilizza il ramo di test.

versione : questo ambiente utilizza il ramo di rilascio effettivo.

Gli sviluppatori lavorano nella sua macchina, ognuno con il proprio database. Se non è possibile ogni sviluppatore ha un singolo database (a causa di licenze, dimensioni del database, ecc.), Ci saranno molti problemi a condividere un database tra gli sviluppatori: quando qualcuno cancella una colonna o una tabella nel suo ramo, gli altri i rami contano ancora con questa colonna / tabella nel database.

Problemi

Il problema più grande in questo processo è l'unione.

Devi rifare le stesse fusioni in test e release . Ciò sarà doloroso se nel codice vengono apportati alcuni buoni refactor, come cancellare una classe, spostare / rinominare metodi, ecc. Dato che non può ottenere codice da test (o release ) diramazione in feature branch, i commit di unione possono essere risolti solo in test (o release ). Quindi, finisci per risolvere gli stessi conflitti in due rami diversi, probabilmente producendo codice diverso in ogni unione e, in futuro, scoprirai che il team di test dovrà testare le funzionalità due volte: in test e release rami, perché ogni unione può causare diversi errori.

Un altro problema è il ramo test . Dovrai "riciclare" questo ramo (eliminarlo e crearne uno nuovo da master ) di tanto in tanto, poiché alcuni vecchi rami (o vecchie unioni, rami uniti che sono stati eliminati) possono portare molti problemi nuovo codice, divergendo molto da ciò che è in master . In questo momento, hai bisogno del controllo di quali rami desideri fondere nuovamente in test .

La soluzione migliore è che il team aziendale sa cosa deve essere consegnato nella prossima versione e tutti lavorano in un ramo univoco (sviluppo ramo). Fa bene a loro la possibilità di scegliere quale caratteristica "fatta" vorrebbero essere nella versione successiva ogni volta che vogliono (penso che questo sia il tuo scenario), ma questo è un incubo per gli sviluppatori e (credo) per il squadra di test.

risposta data 22.11.2016 - 16:58
fonte

0

Sembra che tu stia unendo modifiche dal tuo ramo di integrazione al tuo ramo di produzione, che IMHO non è una buona pratica, esattamente per le ragioni che hai menzionato. Non appena un ramo di produzione per una determinata release viene estratto dal ramo dell'integrazione principale, il ramo dell'integrazione può divergere in qualsiasi momento (dopotutto dovrebbe evolvere nella prossima versione). La fusione dal ramo di integrazione nel ramo di rilascio corrente può apportare modifiche incompatibili con tale versione.

IMHO un processo corretto sarebbe:

estrae un ramo di produzione dal ramo di integrazione solo quando si ritiene che sia abbastanza vicino al livello di qualità desiderato, in modo tale che solo una manciata di modifiche dovrebbe completare il rilascio. In altre parole, il completamento della funzione deve essere valutato (continuamente) sul ramo di integrazione, prima di estrarre il ramo di produzione.

dopo che il ramo di produzione viene estratto vengono apportate solo modifiche selezionate, trattate come modifiche autonome / puntuali - ovvero verificato che funzionino come previsto (solo perché una modifica funziona in un ramo non significa necessariamente funziona anche in un altro ramo).

risposta data 22.11.2016 - 16:06
fonte

0

Personalmente, sembra che potrebbe essere un problema di processo più che un problema di strumenti. Alcune cose che suggerirei qui:

Non sono sicuro che tu abbia gruppi Dev e QA separati. Se lo fai, assicurati che sia Dev che QA partecipino alle riunioni di pianificazione e stima dello sprint. In una delle mie precedenti società, ci siamo assicurati che il numero di story point a cui assegnavamo una storia corrispondesse sia allo sviluppo sia alla sperimentazione. (Potresti anche teoricamente avere due stime separate per lo sforzo Dev e QA, ma in entrambi i casi hai bisogno che la tua stima includa entrambi: il tempo richiesto per una storia è il tempo richiesto per consegnarlo effettivamente). Anche se non hai un gruppo QA separato, assicurati di includere lo sforzo di test nelle stime.

Seguendo una vena simile a quella sopra, concorda in anticipo su quante storie includerai in uno specifico sprint. Il numero di punti storia che accetti si basa sulla quantità che gli sviluppatori possono completare nello sprint e del numero di elementi che il QA può testare nel loro sprint. (Sto presumendo, ovviamente, che gli sprint di QA siano dietro agli sprint di Dev, ma puoi adattarli al tuo processo). Se i tuoi sviluppatori possono completare 200 story points ma il tuo QA può solo completare 150 story points, ovviamente puoi fare solo 150 story points prima che il lavoro inizi a "accumularsi" e finisci con un caso come quello che descrivi. (In un caso come questo, potresti voler indagare sulla causa del roadblock per cercare di mitigarlo).

Nessuno spinge nulla al QA finché tutto ciò che è attualmente in QA è testato e consegnato .

Una funzionalità completa è quella che è stata testata e consegnata. Se non viene consegnato non è fatto.

Ovviamente, vuoi provare a farlo su una sorta di programma fisso. Una delle idee complete di Continuous Integration e Agile è l'iterazione. Per definizione, l'iterazione comporta una consegna frequente. Frequenti integrazioni e consegne riducono al minimo il rischio di ciascuno.

Onestamente, ritengo che la cosa più importante sia la disciplina in merito al momento della pubblicazione e il numero di attività che puoi completare completamente in un determinato lasso di tempo.

Riassumendo: consegna solo al QA quando hai finito di testare e consegnare le vecchie funzionalità.

risposta data 22.11.2016 - 18:45
fonte

-2

Quando "tutto è testato e approvato", distribuire quello che è stato testato e approvato per la produzione. Questo potrebbe essere un commit particolare o potrebbe essere un particolare manufatto generato da Jenkins.

Non dovrebbe importare che i successivi commit sullo stesso ramo non siano ancora testati.

risposta data 23.11.2016 - 00:54
fonte

Leggi altre domande sui tag git branching continuous-integration devops

Come eseguire le riunioni del team degli sviluppatori? Come migliorare l'efficienza con la programmazione funzionale?

score 22 · Accepted Answer

Sembra che tu abbia alcuni problemi qui:

1. Identificazione di funzionalità per una versione specifica

Questo è un problema di gestione del progetto e un problema di coordinamento. La funzione questa sarà rilasciata prima, nello stesso momento o dopo questa altra funzione? Se i rilasci vogliono accadere una funzione alla volta, allora identificali. Se le caratteristiche verranno raggruppate in versioni, quindi capire quali sono i raggruppamenti e applicarli con i responsabili e ai responsabili delle decisioni. Usa il tuo sistema di tracciamento o emissione dei biglietti per taggare i comunicati. Metti in chiaro che se una caratteristica di una specifica release è un no-go, allora sono tutte.

2. Strategie di ramificazione

Git-flow è la risposta facile per problemi come questi, e spesso le persone usano una variante di git-flow anche se non sanno cosa sia. Non dirò che è un trucco per tutti i problemi, ma aiuta molto.

Sembra che tu stia imbattendo in un problema con strategie di rilascio non deterministiche, in cui le funzionalità sono approvate scattershot e qualcosa che ha iniziato lo sviluppo molto tempo fa potrebbe essere rilasciato dopo qualcosa che è stato avviato più di recente: le funzionalità di leap-frog.

Filiali caratteristiche a lungo termine o rami di rilascio simultanei sono probabilmente la risposta migliore per questo tipo di problemi. Unisci (o rebase, se ti senti a tuo agio con esso) l'ultimo dal master nei tuoi rami di lunga data. Fai attenzione a solo unire in funzioni già esistenti, altrimenti ti imbatterai nei problemi che hai avuto ora (troppe funzioni miste su un ramo).

I rami "Hotfix" o "bugfix" sono una parte essenziale di questo processo; usali per piccole correzioni una tantum con un ciclo di QA breve.

Dalla tua descrizione, potrebbe anche essere meglio non mantenere un ramo "di sviluppo" ufficiale. Piuttosto, separa tutte le funzioni dal master e crea rami di rilascio uniti una volta identificato il rilascio.

3. Ambienti

Non associare i rami git ai tuoi ambienti, ad eccezione della produzione == master. Il ramo "sviluppo" dovrebbe essere considerato rotto. I rami di rilascio vengono spinti per testare gli ambienti, sia che si tratti di un ambiente di controllo qualità o di un sistema di gestione temporanea. Se è necessario, inserire un ramo di funzione specifico in un ambiente.

Se hai più di un ramo di funzionalità che devono essere rilasciati separatamente ma vengono testati contemporaneamente ... ¯ \ _ (ツ) _ / ¯ .... far girare un altro server? Forse unirli insieme in un ramo di riserva ... commetti correzioni / modifiche ai rami originali e ri-unisci nel ramo di lancio; fai l'approvazione finale e la UAT sui singoli rami di rilascio.

4. Rimozione di funzionalità non approvate da un ramo

Questo è ciò che i pensieri di cui sopra stanno cercando di evitare, perché questa è senza dubbio la cosa più dolorosa da provare e fare. Se sei fortunato, le funzionalità sono state unite nel tuo sviluppo o testare filiali atomicamente usando commit di unione. Se sei sfortunato, gli sviluppatori si sono impegnati direttamente nel ramo sviluppo / test.

In ogni caso, se ti stai preparando per una versione e hai modifiche non approvate, dovrai utilizzare Git per indietro quei commit non approvati dal ramo di rilascio; l'idea migliore è quella di prima testare la versione.

Buona fortuna.