È possibile eseguire una distribuzione continua con programmatori junior?

C'è un momento in cui cominci a capire che, nell'architettura dei micro servizi, è più spaventoso aspettare una settimana per distribuire tutti i micro servizi contemporaneamente per assicurarsi che tutto funzioni insieme, piuttosto che applicare rigorosamente il controllo delle versioni di API, scrivere un sacco di automatico test (un po 'ciascuno: unità ed esplorativo, integrazione) e distribuzione automatica in produzione non appena il commit passa come test sul palco.

Ora, sembra un'ottima idea fintanto che ti ricordi di scrivere test, testare le modifiche prima di impegnarti, sapere come utilizzare il controllo delle versioni API e non lascerai cadere il database nello script di aggiornamento db incrementale che viene eseguito sulla distribuzione (che non è un grosso problema in quanto dovrebbe fallire sul palco).

Ma è possibile farlo con programmatori junior? Forse dovrò implementare lo schema pull-request. Ciò renderebbe meno come la distribuzione continua (questa è la mia ipotesi)?

Spero che questo non sia basato sull'opinione e posso contare sul fatto che tu condivida la tua esperienza, grazie.

Si prega di notare che non sto chiedendo informazioni sulla CI né sulla consegna continua. Lo abbiamo già. Quello che stiamo provando ora è di renderlo una distribuzione continua, il che significa avere tutto in produzione subito dopo il check-in del codice.

Perchè no? Qualunque delle cose che descrivi sarebbe un problema se si utilizza la distribuzione continua o meno. Il problema, a quanto pare, è che sei preoccupato che i giovani commettano un errore catastrofico. E quell'errore sarà precipitato nella produzione prima che chiunque possa colpirlo.

Ecco perché fai revisioni del codice ed esegui test. Prima che qualcosa venga unito al tuo ramo principale e previsto per il rilascio, richiedi che venga rivisto il codice, sia da alcuni altri junior (in modo che acquisiscano esperienza) sia da sviluppatori senior (per utilizzare la loro esperienza per migliorare il codice). Tutti dovrebbero essere alla ricerca di questi bug catastrofici. E dovrebbe fermarli. In caso contrario, probabilmente avrai bisogno di alcuni QA / test migliori in un ambiente di gestione temporanea (e forse alcuni sviluppatori migliori se le recensioni del codice mancano queste cose).

La distribuzione continua funzionerà bene se si dispone di una buona serie di test automatizzati.

Gli sviluppatori junior possono essere entusiasti del proprio compito e non vedere che si rompono le cose. Puoi risolverlo con un po 'di automazione. Imposta un server di build che eseguirà i test in qualsiasi momento e ottieni loro uno strumento come CatLight build notifier . Darà loro un feedback rapido e chiaro quando romperanno le cose.

Risolveranno piccoli problemi man mano che si verificano e manterranno la consegna continua in esecuzione.

L'unico modo per imparare le buone abitudini è esercitarle, quindi sì gli sviluppatori junior possono anche esercitarsi in una distribuzione continua. Potresti pensare di aggiungere alcuni passaggi alla pipeline per fare cose come controllare la copertura del test ed eventualmente eseguire un'analisi del codice statico e fallire la costruzione se la copertura del test non è abbastanza alta. Ciò garantirà che gli sviluppatori junior comprendano le aspettative prima che qualcosa sia considerato completo.

Non solo puoi farlo con sviluppatori junior, ma è richiesto da te. Innanzitutto, ridurrai la qualità del tuo software altrimenti, e in secondo luogo questo aiuta gli sviluppatori junior ad apprendere buone capacità di sviluppo software.

Come analogia: vorresti che il tuo dottore non praticasse la medicina al meglio delle sue conoscenze perché avrà paura di errori di apprendistato giovani? In che modo i medici affrontano il danno potenziale?

Dall'esperienza passata con una base di codice Big Ball Of Mud che si è evoluta naturalmente nel corso degli anni per mano di molti sviluppatori junior senza supervisione, vorrei sottolineare cosa succede quando non si pratica la CI con quegli sviluppatori.

Modifica / Aggiorna : come da commento di RubberDuck; questa risposta presuppone che l'obiettivo di unione per l'integrazione sia un ramo di sviluppo piuttosto che un ramo di valutazione o di rilascio.

• Ovviamente è necessario un maggiore controllo sul codice per il rilascio e la distribuzione live; se non esiste un ramo di produzione separato, varrebbe la pena prendere in considerazione una modifica alla strategia di diramazione / fusione per eseguire un ramo di sviluppo principale (che viene utilizzato per i test di integrazione e mai per il rilascio) insieme al ramo di rilascio principale. Ciò mantiene tutti i vantaggi di CI e fusioni frequenti senza rischiare di rompere il codice di produzione.

1. Gli sviluppatori junior hanno meno probabilità di comunicare con i loro colleghi o supervisori

L'integrazione continua non è semplicemente una questione di fusione nel codice, è un momento nel quale uno sviluppatore è costretto a interagire con altre parti interessate.

La comunicazione è importante e senza voler esagerare con la generalizzazione, tende ad essere un'abilità appresa che arriva in modo meno naturale agli sviluppatori inesperti rispetto a quelli che sono abituati a lavorare in un ambiente di squadra.

Se si consente agli sviluppatori junior di sedersi nel proprio cubicolo e scappare via al codice per settimane senza che vengano richiesti rapporti / recensioni frequenti, è più probabile che evitino del tutto la comunicazione.

2. È probabile che il codice che stanno producendo necessiti di una revisione più rigorosa

Hai mai recensito qualcosa di così brutto da desiderare di averlo raccolto prima e di non averlo mai scritto? Questo succede molto.

Non è possibile impedire la scrittura di codice errato, ma è possibile limitare il tempo perso. Se ti impegni a frequenti revisioni e fusioni, riduci al minimo l'ambito per perdere tempo.

Lo scenario peggiore è che potresti lasciare uno sviluppatore junior da solo per diverse settimane nel suo progetto in miniatura e quando sono finalmente pronti per la revisione del codice, semplicemente non c'è abbastanza tempo rimanente per buttare tutto il casino via e ricominciare da zero.

Molti progetti diventano una grande palla di fango semplicemente perché un intero carico di codice errato è stato scritto quando nessuno prestava attenzione fino a quando non era troppo tardi.

3. Dovresti essere meno sicuro che uno sviluppatore junior o un altro nuovo membro del team abbia compreso i requisiti

A volte uno sviluppatore potrebbe creare la soluzione perfetta al problema sbagliato; questo è triste perché di solito si tratta di semplici equivoci che sarebbero così facili da evitare se solo qualcuno avesse posto le domande giuste in precedenza nel processo.

Ancora una volta, questo è un problema che ha maggiori probabilità di influenzare gli sviluppatori inesperti che hanno maggiori probabilità di accettare requisiti "cattivi" al valore nominale invece di respingere e mettere in discussione la saggezza del requisito.

4. È probabile che abbiano meno familiarità con i modelli comuni, con l'architettura del codice esistente e con strumenti e soluzioni noti

A volte uno sviluppatore trascorre un sacco di tempo reinventando inutilmente la ruota semplicemente perché non sapeva che esisteva una soluzione migliore. Oppure potrebbero passare giorni cercando di martellare un piolo quadrato in un buco rotondo senza rendersi conto di ciò che stanno facendo di sbagliato.

Ancora una volta, questo genere di cose è più probabile che accada a sviluppatori inesperti e il modo migliore per affrontare il problema è garantire revisioni regolari.

5. Lunghi periodi tra commit e fusioni del codice rendono più difficile identificare e correggere i difetti

Quando un bug emerge immediatamente dopo molte settimane di modifiche al codice sono state unite nel ramo principale, la sfida di identificare quale modifica potrebbe aver causato il bug diventa più difficile.

Ovviamente qui entra in gioco anche la tua strategia di ramificazione generale; idealmente tutti i tuoi sviluppatori lavoreranno nei loro rami o all'interno di rami funzione (o entrambi) e non funzioneranno mai direttamente dal master / trunk.

Ho visto situazioni in cui interi team lavorano tutti direttamente nel master / trunk allo stesso tempo, e questo è un ambiente terribile per CI, ma fortunatamente la soluzione di allontanare tutti dal master / trunk in genere fornisce abbastanza stabilità per il lavoro individuale articoli / biglietti / etc.

Dovrebbe sempre essere "OK" per qualsiasi sviluppatore rompere il ramo master / trunk, con la consapevolezza che la fusione dovrebbe avvenire su una base così regolare, che la rottura di cambiamenti e difetti dovrebbe essere identificata più rapidamente e quindi risolta anche più rapidamente. I difetti peggiori sono in genere quelli che rimangono inosservati per mesi o addirittura anni.

In sintesi; i principali vantaggi dell'integrazione continua / implementazione continua sono:

• La comunicazione tra il tuo team migliora
• La qualità del codice è generalmente mantenuta a uno standard più elevato
• È meno probabile che i requisiti vengano persi o male interpretati
• I problemi di architettura e design dovrebbero essere rilevati più rapidamente,
• È più probabile che i difetti vengano rilevati e risolti in una fase precedente

Quindi, se non stai praticando CI con i tuoi sviluppatori junior, stai accettando molti rischi non necessari significativi, poiché questi sono i membri del tuo team che ne hanno bisogno più degli altri.

Sì, puoi esercitarti in CI con sviluppatori junior. Sarebbe stupido non farlo nell'attuale clima di sviluppo. È follemente utile poter spingere al repository e poi farlo fondere automaticamente nel codice di staging - e guardarlo tutto in tempo reale su Travis (o Bamboo, Pipeline ecc ...)!

Prendi il tuo ragazzo DevOps e fagli passare il processo con loro, oltre a un dev senior in standby solo per controllare le cose e collegarlo con le loro recensioni di codice (fai quelle, giusto?)

Se la tua preoccupazione è che il codice shite sta per passare, quello non è sull'elemento della configurazione e non è sui juniors: è su di te .

Quindi aiutali a migliorare e ad abituarsi a distribuire più rapidamente il codice stage / prod. Ti ringrazierai a lungo termine.