È ragionevole che DevOps insista sull'integrazione con 2 filiali?

Question

È ragionevole che DevOps insista sull'integrazione con 2 filiali?

#1 da (6 voti)
#2 da (3 voti)
#3 da (-1 voti)

-4

Sono DevOps / CI per il mio team di circa 10 sviluppatori. Sviluppiamo e implementiamo una sofisticata applicazione per la raccolta e la visualizzazione di dati scientifici. Sono la persona che ha introdotto CI al mio team e standardizzato e semplificato il processo di compilazione usando Jenkins, Maven, Python ecc. Usiamo Subversion per il controllo delle versioni, che non è la mia preferenza (ovviamente Git è) ma posso lavorare all'interno di quei parametri . L'argomento di questa indagine è la nostra strategia di ramificazione, che sto cercando di promuovere in una politica.

Come qualcuno che gestisce tutto il ciclo di vita oltre il punto di controllo delle modifiche, la mia preferenza è di non dover supportare più di due rami di codice: (1-PROD) che è attualmente distribuito in PROD e (2 -DEV) ciò che è in sviluppo. Questo semplice scenario semplifica la mia vita e la mancanza di flessibilità per quanto riguarda le filiali è ciò che consente efficienza e buon funzionamento nel mio dipartimento. Avere un singolo ramo unificato per release e non avere rami di funzionalità elimina la necessità di unire, il che è sempre un crapshoot, per usare un eufemismo. Quindi, il modello che sto proponendo richiederebbe, in teoria, di non unire mai nulla: se uno sviluppatore apporta modifiche alla PROD in 1-PROD, (s) è responsabile di applicare tali modifiche a 2-DEV, in modo che non Non dobbiamo fare fusioni nel processo di CI. Mantiene le cose pulite e stabili .

Tuttavia, vi è una tendenza all'interno del team e la gestione a ricorrere alla creazione di una nuova succursale ogni volta che si manifesta la minima discrepanza nei requisiti, e molte di queste potrebbero essere affrontate all'interno della stessa filiale, ad es. Commutando la funzionalità in sospeso utilizzando la configurazione finché non è pronta ecc. In ogni istanza di un nuovo ramo che è stato creato, ho dimostrato che l'isolamento dello sforzo di sviluppo poteva essere realizzato all'interno del ramo esistente utilizzando le impostazioni di configurazione. Non vorrei odiare lo stesso se non richiedessero anche che gli artefatti di build ufficiali venissero generati e distribuiti a varie istanze di test da quei rami (la distribuzione di PROD esce sempre dal ramo principale dopo che ogni possibile ramo di funzionalità è stato integrato). Quindi, se vogliono avere 100 filiali per gli sviluppatori, per me va bene purché siano responsabili di unirle in uno dei due rami che mi riguardano e io non devo supportare la distribuzione da lì a istanze reali. Anch'io lo odio di meno se più filiali non implicano l'orribile processo di fusione, che odio e cerco assolutamente di progettare un ambiente in cui non è fatto.

La mia proposta di strategia di ramificazione / implementazione (per supportare solo i due rami canonici nel processo di integrazione) è irragionevolmente semplicistica? La complicazione / entanglement associato alla flessibilità della ramificazione è semplicemente un fatto della vita nel mondo di DevOps / CI?

branching devops

posta amphibient 02.10.2018 - 20:14

fonte

3 risposte

Leggi altre domande sui tag branching devops

Perché diverse lingue hanno una sintassi diversa? [duplicare] ASP./IIS ambiente di runtime [chiuso]

score 6 · Answer 1

Il ruolo di DevOps è di consentire a l'autosufficienza tra gli sviluppatori , di non occuparsi personalmente di tutto il lavoro.

Credo che tu abbia ragione incoraggiando gli sviluppatori a utilizzare i pulsanti di funzione, ma irragionevolmente limitandoli a due soli rami.

Le funzioni di attivazione / disattivazione funzionano bene per le nuove funzionalità che non si sovrappongono ad altre funzionalità, ma alla fine ti troverai in una situazione in cui devi riesaminare qualcosa di critico. La creazione di un nuovo ramo è un modo semplice per consentire modifiche importanti.

Se utilizzi Jenkins, non dovrebbe essere troppo difficile creare e testare qualsiasi quantità di filiali e distribuire le risorse in ambienti di test. Un vantaggio di questo è la possibilità di notificare gli sviluppatori quando il loro ramo non riesce a costruire e impedire loro di infrangere il ramo dev.

Nel mio precedente ruolo, sono stato in grado di creare un'istanza di Jenkins che gestiva centinaia di build al giorno da molte filiali e gli sviluppatori / QA potevano utilizzare i lavori per distribuire gli artefatti ovunque volessero. Il punto è che loro erano responsabili di fare il lavoro, ho semplicemente dato loro gli strumenti di cui avevano bisogno.

score 3 · Answer 2

This simple scenario makes my life easy and the lack of flexibility with regard to branches is what enables efficiency and smooth operation in my department.

Se funziona in modo impeccabile, ciò mi suggerisce che le funzionalità che si stanno impegnando non sono in conflitto tra loro.

Se le due funzionalità non sono in conflitto, non si verificherebbe comunque un problema di unione da un ramo.

Se le due caratteristiche sono in conflitto, dovresti gestire le unioni in entrambi i casi (unione di rami o risolvere un conflitto di aggiornamento che SVN ti impone di fare prima di arrivare a commettere il tuo codice).

the need for merging, which is something that is always a crap chute, to put it mildly

Il problema qui è uno di percezione.

Senza rami aggiuntivi, non devi preoccuparti di problemi di unione, ma invece ti imbatti nel problema continuo degli sviluppatori che interrompono il ramo e bloccano tutti gli altri. Questo può accadere in qualsiasi momento, praticamente ogni giorno se si applica una politica di commit del codice alla fine della giornata.

Con i rami extra, in realtà rimandi quei conflitti finché non è il momento di unire.

Mentre i problemi di unione sono più complicati da affrontare, si verificano anche nei termini (solo quando si desidera unire), piuttosto che ogni commit è soggetto a interrompere la generazione per tutti.

Quando si somma la quantità di impegno speso, si noterà che i numerosi problemi di commit richiederanno più tempo (specialmente quando interessano più sviluppatori) rispetto a un singolo sviluppatore che deve dedicare uno sforzo per unire i rami. / p>

In secondo luogo, esiste un conflitto intrinseco con l'applicazione di una politica di commit giornalieri. Che cosa succede se uno sviluppatore sta lavorando su un cambiamento importante (uno che cambia le cose in un modo meno che banale) che richiede probabilmente diversi giorni per completare?

Questo sviluppatore dovrebbe ignorare la politica da eseguire quotidianamente? Questo è male, perché diventa una pista scivolosa di persone che decidono da sole quando si sentono pronti a commettere un codice.
Lo sviluppatore dovrebbe commentare le sue modifiche e commettere l'applicazione in modo che funzioni come prima? Ciò richiede uno sforzo supplementare e apre la porta a dimenticare di decommentare una o due parti dei cambiamenti e quindi imbattersi in comportamenti imprevisti. E questo è anche supponendo che le modifiche non influiscano drasticamente sulle classi / file perché diventano impossibili da gestire.
Lo sviluppatore dovrebbe impegnare il codice così com'è, anche se è incompleto e quindi renderà l'applicazione inutilizzabile fino a quando lo sviluppatore non avrà completato la sua attività?

Non c'è una buona opzione qui. Ma se utilizzi i rami delle funzioni, allora compartimenti stagionali il problema. Chiunque stia lavorando sul cambiamento di rottura può farlo al proprio ritmo, nella propria branca. Solo quando sono finiti (cioè hanno un codice funzionante), si fondono nel codice "condiviso".

Inoltre, ci sono modi per minimizzare l'impatto. Fai in modo che i tuoi sviluppatori di feature si uniscano dal carrello al loro ramo di funzionalità e risolvano i conflitti di unione in questo modo. Ciò abbassa drasticamente l'emergere di conflitti di fusione durante l'unione dal ramo della funzione al trunk.

Inoltre, farei in modo che la fusione di un ramo di funzionalità sia responsabilità dello sviluppatore di quel ramo di funzionalità. In realtà stai già applicando questo principio; quando condividi un trunk, SVN ti obbliga a aggiornare e risolvere eventuali conflitti potenziali prima di consentire il commit.

Puoi rispettare la stessa politica per i tuoi rami di funzionalità; dove viene chiesto agli sviluppatori di unire prima il tronco al ramo, risolvere i conflitti lì (al proprio ritmo, senza influenzare gli altri) e quindi unire dal ramo al tronco.
È ancora possibile che ci sia stato un nuovo commit al trunk tra le due operazioni di unione, ma le probabilità sono basse, e anche se i conflitti si verificano, saranno relativamente piccoli (e quindi non inclini a unire errori).

score -1 · Answer 3

Sì, la tua strategia sembra a posto. Con i seguenti avvertimenti.

Gli sviluppatori possono ancora creare tutte le filiali di funzionalità "non costruire in CI".
Si aggiunge un terzo ramo CI "Test" per consentire all'avvio di 1.2 di iniziare mentre è in corso il test di 1.1 e 1.0 è ancora attivo e potenzialmente ha bisogno di aggiornamenti rapidi.

È possibile disporre di elementi di configurazione per qualsiasi ramo, ma in realtà è necessario disporre di un ambiente separato per la distribuzione di tale ramo. che di nuovo, in questi giorni di nuvole, può essere fatto. Ma diventa costoso veloce ed è generalmente molto più difficile da raggiungere.

Penso che la maggior parte dei posti avrà un live, dev e test di installazione di installazione e lavorare intorno a questo. Forzare una strategia di rilascio e una tabella di marcia in cui le release delle caratteristiche hanno un grado di flessibilità nell'ordine in cui possono essere rilasciate.

Tuttavia, devi capire che questo è essenzialmente un problema di gestione e controllo su come le persone lavorano. Non un semplice processo tecnico. La migliore soluzione tecnica non è sempre la soluzione selezionata in questi casi.