Problemi di politica di integrazione continua

Cercherò di mantenere la risposta concentrata su

How could we make this process more obvious?

parte della domanda che hai chiesto. I processi più semplici tendono a ottenere una risposta "ovvia" dagli utenti, ma sono difficili da articolare e sviluppare.

Alcune cose che non vedo nel diagramma o non so se esistono nella tua documentazione;

• In che modo le modifiche al codice scorrono attraverso il processo w.r.t. il repository. Usiamo SVN, ma abbiamo modellato molti dei nostri flussi di codice interni su git flow con molto successo. Non sto sostenendo una modifica del repository o un flusso di lavoro per te, ma ci sono un certo numero di idee chiare su come documentare i flussi del codice e su dove ogni build deve venire dalla base di codice.
• Detto questo, un cambiamento nei flussi di lavoro del codice può essere d'aiuto. A seconda del tempo specifico e di altri vincoli fisici, eseguire il test interno e il ciclo di QA prima che i cicli client possano essere d'aiuto. Gli artefatti dei tuoi cicli interni saranno quindi gli input per i cicli dei clienti. Questi possono ancora essere eseguiti in parallelo, dato che possono essere lavorati fisicamente allo stesso tempo. Ma non sarebbero paralleli, in quanto ciò che è prodotto in uno sarà disponibile solo più tardi all'altro - come voi lo avete già adesso. Penso che questo sarà un compromesso tra risorse, tempo e problemi di business e tecnologia. Posso pensare a scenari in cui entrambi funzionerebbero.

Ulteriori modifiche al processo;

• Semplifica la documentazione, anche se serve solo a ridurne il volume. Parte del problema qui sarà la formazione degli utenti. Rendere più facile per le persone comprendere e utilizzare correttamente il processo ridurrà l'onere per te.
• Brevi elenchi definitivi degli artefatti di ogni fase, questi possono essere usati come check-list per conformità e risoluzione delle query.
• Definisci il più chiaramente possibile le catene parallele del processo e la separazione tra loro. In che modo le informazioni (e il codice) fluiscono tra loro, se non del tutto? Qual è la differenza tra le due fasi di accettazione alla fine di ciascuna di esse? E così via.
• Definire utili punti "ripristinati"; se un passo fallisce, il processo torna al passaggio precedente o all'inizio del processo o sono i punti più significativi per tornare, correggere e continuare. Definisci come queste correzioni tornano a dev .

Produrre un processo semplice e intuitivo è difficile, cambiarlo è ancora più difficile. In generale, rimuovere i passaggi non necessari, confusi o non intuitivi è meglio modificarli, e anche quello è meglio che aggiungere qualcosa.

Credo che sia stato Antoine de Saint-Exupéry a dire originariamente (ha ripetuto varie forme nel corso degli anni);

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

Da wikiquote

Non sembra così male tutto sommato.

Ok, quindi vuoi i rami delle funzionalità nel flusso di lavoro del tuo repository. Semplice:

Dove dice 'release build', devi creare un tag con il numero di versione appropriato e usarlo per creare le versioni. Ti consente di rispondere al feedback dell'integrazione e del test del QA applicando le modifiche al tag (e passando di nuovo le modifiche a dev per una correzione futura)

Dove dice "dev" hai bisogno di un ramo per caratteristica. Queste sono le build che passano attraverso i test interni, quando vengono passate vengono fuse sul trunk. Una volta unito, il ramo viene eliminato (eventuali correzioni che trovi dopo questo devono essere corrette come nuove dir di sviluppo o ti ritrovi in un sottaceto dato il tuo processo complessivo).

Non penso sia così difficile tutto sommato. Fondamentalmente le frecce che puntano dalla casella Deposito a Integrazione dovrebbero diventare molte frecce, una per ogni ramo o tag che hai. Quindi hai uno sviluppo parallelo e il problema diventa quello di gestire tutte le diverse build e configurazioni che vanno con loro ... ma questa è una storia diversa.