Trovare argomenti convincenti per spiegare una pipeline di integrazione continua progettata male

Sto progettando una pipeline di integrazione continua usando Bitbucket & Jenkins con solo master e rami delle funzionalità. Non riesco a trovare argomenti convincenti sul fatto che il mio design sia migliore.

* Il nostro processo di compilazione include la compilazione del codice di frontend e back-end (stesso repository), esegue test di unità frontend e backend & Cucmber, test end-to-end frontend, test di carico back-end.

Dal mio punto di vista, una delle parti più importanti in esso, è avere 2 condizioni prima una richiesta pull può essere approvata :

a. un ramo di funzionalità, che hai inserito, deve contenere l'ultimo commit dal ramo master remoto.

b. una build remota e automatica deve passare sul contenuto del ramo della tua funzione.

An alternative to conditions a and b is to have one successful build on the merged content between the remote master and your feature branch you pushed.

Attualmente, la nostra pipeline per l'integrazione continua prevede un ulteriore ramo: development .

La mancanza di esperienza con i webhook o il desiderio che le cose vengano fatte in un certo modo hanno permesso ai miei collaboratori di progettare un CI in cui richiamiamo richieste al ramo development e non appena il nostro server Jenkins scopre che development il ramo è stato aggiornato (chiedendo ogni X secondi), esegue una nuova build.

Se la compilazione ha esito positivo, il lavoro viene inoltrato anche al master remoto unendosi tra lui e development . Altrimenti, se la compilazione fallisce, non accade nulla.

Sto affrontando 2 problemi. Il primo è trovare argomenti convincenti per il team di devops, che è responsabile di progettare il nostro sistema di CI, perché dalla mia comprensione, la mia soluzione coinvolgerà l'apprendimento aggiuntivo e, soprattutto, molto più tempo per finire. Penso che in realtà, i team di devs non abbiano gli stessi interessi dei nostri team di sviluppatori perché, in ultima analisi, non utilizzano i prodotti che progettano o costruiscono per i team di sviluppo.

Il secondo e ultimo problema è trovare argomenti convincenti per i manager che possono cambiare le cose. È estremamente difficile convincere una persona che non ha competenze tecniche con Git, modelli di integrazione continua, Bitbucket e così via : "Github e Bitbucket sono esattamente gli stessi". Ricevo sempre la stessa risposta: "Funziona per ora, e la tua soluzione potrebbe essere migliore ma ha bisogno di troppi sforzi per raggiungere e non aggiunge un vero valore aziendale al momento" .

Gli aspetti negativi che ho trovato finora per il vecchio design:

1. Tutti hanno i permessi di lettura su% co_de remoto. Può includere commit che appartengono a richieste pull con build fallite. Significa che non posso sapere o fidarmi di alcun commit nella cronologia di quel ramo se contiene contenuti validi o meno. Allora perché devo vedere questo ramo nella cronologia del repository?

2. È meglio tirare solo da development e non da master . In rari (?) Casi, gli sviluppatori estraggono da development perché " sanno che la build non fallirà per questa particolare richiesta di pull " quindi non c'è motivo di aspettare fino a quando quel contenuto sarà disponibile dal ramo development remoto. Nel caso in cui la richiesta di pull fallisca, hanno tirato il commit sbagliato e potrebbero metterli nei guai più tardi.

3. Nel caso in cui una richiesta pull sia approvata e la build passata, quindi per qualche motivo (un bug o un cattivo design), vogliamo "tornare indietro" (questo è disponibile in Github e Bitbucket) e cancellare l'ultimo richiesta pull, ora ho bisogno di ripristinare 2 rami invece di uno. Inoltre ci possono essere più persone che tirano da master e master , quindi è estremamente difficile da cancellare ora.

4. Bitbucket offre molti webhook che possiamo usare, perché non usarli invece di tirare ogni 2 secondi da Jenkins a Bitbucket se accade un evento specifico (i commit sono stati aggiunti al ramo development ):

   • Repository: push, fork, aggiornato, commento di commit creato, stato di creazione creato, stato di compilazione aggiornato.
   • Problema: creato, aggiornato, commento creato
   • Richiesta pull: creato, aggiornato, approvato, approvato rimosso, unito, rifiutato, commento creato, commento aggiornato, commento eliminato

I professionisti che ho trovato finora nel mio progetto:

1. Elimina tutti gli svantaggi che ho trovato in precedenza.
2. Non si perde tempo a rivedere una richiesta pull che non è riuscita nel processo di compilazione.
3. Meno rami, più facile da capire la cronologia del repository.

Come descriveresti l'importanza di questo tipo di cambiamento nel nostro CI?