Nell'interesse del miglioramento continuo sono interessato a trovare modi per migliorare il nostro processo di sviluppo del software. Ci sono molti articoli là fuori che definiscono una serie di flussi di lavoro, ma tutti adottano sempre un approccio semplice: 1 repository, 1 team, 1 prodotto, 1 flusso. Ma nessuno di loro sembra coprire come qualcosa di simile possa essere implementato su una scala più ampia, o quando il budget è un fattore.
Siamo una piccola squadra di sviluppatori che lavorano su un singolo prodotto, che consiste in più applicazioni. Quando sviluppiamo una funzionalità, o risolviamo un bug, allora è interessata più di una applicazione. Usiamo scrum con uno sprint di sviluppo di 2 settimane, quando finiamo il nostro sprint distribuiamo tutto nel nostro ambiente QA che viene poi testato durante il prossimo sprint. Dopo quelle due settimane di test del QA, andiamo a vivere.
Abbiamo due applicazioni desktop, A e B, utilizzate dai nostri dipendenti. Ogni applicazione ha uno scopo e un diverso insieme di utenti. Disponiamo inoltre di un sito Web, C, utilizzato dai nostri clienti, più servizi REST e un set di servizi Windows utilizzati per eseguire diverse attività pianificate e processi in background. In totale, abbiamo circa 10 applicazioni che funzionano tutte insieme e sono attivamente sviluppate.
Ogni applicazione ha il proprio repository Git e almeno tre rami in ogni momento:
- master: corrisponde al codice di produzione
- versione: corrisponde alla versione distribuita nell'ambiente QA
- develop: corrisponde alla versione distribuita nel nostro ambiente di test
Quando lavoriamo su una nuova funzione, viene creato un ramo di funzionalità dal ramo di sviluppo. Un bug di QA è stato risolto nel ramo di rilascio, unito allo sviluppo in modo che i nostri tester possano verificarlo e implementato solo nell'ambiente di controllo di qualità dopo l'approvazione dei nostri tester. Un bug di produzione è stato risolto sul master, reimmesso nello sviluppo e rilasciato in modo tale che i tester e il QA possano verificarlo e approvarlo, e solo dopo sarà pubblicato per la produzione.
In pratica, significa che un singolo sviluppatore sta lavorando su una singola funzionalità che si estende su più applicazioni e quindi su più repository. Ogni applicazione ha il suo piano di costruzione continua, in cui i rami funzione vengono scoperti automaticamente e le build hanno luogo. Ogni applicazione ha anche il proprio piano di implementazione. Al termine di una funzionalità, lo sviluppatore lo unisce al ramo di sviluppo e avvia manualmente il piano di distribuzione per le applicazioni interessate.
Finora, questo approccio funziona e gestisce perfettamente il nostro ciclo di domande multiple / QA.
Il mio unico problema a questo punto è l'effettivo processo di distribuzione. Usiamo Bamboo, abbiamo un piano di sviluppo di implementazione e un progetto di implementazione che viene attivato dopo il completamento della compilazione. Il processo manuale include che lo sviluppatore deve attivare la build per ciascuna applicazione. E quando distribuiamo al QA o alla produzione, dobbiamo fare affidamento sul fatto che lo sviluppatore abbia documentato quali applicazioni dovrebbero essere implementate in questo sprint. E a volte gli errori vengono fatti o un'applicazione viene dimenticata. Inoltre, non disponiamo delle risorse finanziarie per configurare semplicemente nuovi server per ogni ramo di funzionalità che creiamo, quindi questo è un possibile problema.
Quindi, mi interessa sapere se:
- Qualcuno ha un'idea di come possiamo migliorare, cambiare o fluire. Il nostro principale collo di bottiglia è che non possiamo eseguire distribuzioni di produzione durante l'orario d'ufficio. Quindi distribuire su commit to production non è realmente un'opzione per il nostro branch master.
- Esistono strumenti (come la distribuzione di Octopus o simili) che renderebbe più semplice la nostra implementazione? Ho già pensato di creare una semplice pagina web dove possiamo elencare le versioni e utilizzare l'API REST di Bamboo per attivare i build di distribuzione per ogni applicazione, ma preferisco utilizzare un flusso / prodotto esistente.
Mi sono preso gioco dell'idea di creare un piano di costruzione unico, massiccio, che esegua i dispiegamenti effettivi, ma qualcosa semplicemente urla "sbagliato" su quell'idea.
TL; DR: Come possiamo implementare in modo efficiente una strategia di branching git e un processo di distribuzione su più repository contenenti più applicazioni sviluppate all'interno dello stesso sprint?
Qualunque suggerimento o idea è apprezzata, e se sottovaluti la mia domanda, per favore commenta e spiega perché.