Sono un membro di un team di progetto con una metodologia di rilascio alquanto inusuale (o almeno dal mio punto di vista) e dinamica di squadra. Il modo in cui abbiamo realizzato i rilasci sta sviluppando un unico pacchetto funzionale alla volta, il tutto, come regola generale, da un singolo sviluppatore. Gli sviluppatori lavorano sulle loro aree funzionali virtualmente indipendenti, che sono tutte ugualmente parte dello stesso pacchetto di distribuzione (file WAR e il corrispondente repo Git), contemporaneamente ma non è sicuro o chiaro di quale modifica entrerà in quale ordine. Dipende spesso da chi termina e prima viene testato il materiale. Quindi Dev1 potrebbe funzionare su Change1 in TeamProject e Dev2 funzionerà su Change2 nella stessa applicazione, ea volte le loro modifiche potrebbero essere interdipendenti (come cambiare un'API condivisa) ma non è chiaro quando verranno distribuiti a PROD.
Il modo in cui attualmente gestiamo la gestione delle filiali di Git è che ogni modifica ha il proprio ramo remoto, che defacto significa che esiste un ramo remoto per sviluppatore. Il problema più grande che vedo è che, per essere aggiornato sulle modifiche del tuo compagno di squadra, devi sincronizzare manualmente il tuo ramo con il loro ramo, che è un processo manuale e spesso un PIA, scusa il termine. Potrebbe essere ok per lo sviluppatore la cui versione è la prossima in linea, per il suo ramo è come apparirà la prossima versione della release una volta che è stata rilasciata (nell'attuale configurazione della singola modifica della release). Ma sicuramente non funziona per lo sviluppatore il cui rilascio arriva subito dopo come (s) che deve costruire le loro modifiche in cima alle modifiche del primo sviluppatore. Tuttavia, non vogliono che il secondo sviluppatore inserisca nel ramo del primo sviluppatore il compito di mantenere intatta la modifica ed escludere tutto il resto da quella specifica release. Quindi il secondo sviluppatore deve fare la fusione del ramo del primo sviluppatore nella sua filiale e poi spingere la sua roba in quel ramo in cima alle modifiche del primo dev. Ciò non sarebbe male se fosse chiaro chi è il 1 ° e chi è il secondo sviluppatore, IOW, le cui modifiche verranno prima srotolate ma che è una contingenza, come spiegato sopra.
Ora, per la natura di questo post finora, è chiaro che io non sono il padre di questo processo e che sono consapevole di molti dei suoi difetti intrinseci. Un difetto notevole è accaduto di recente quando promuovevamo le nostre modifiche all'ambiente TEST. Avevo lavorato nella mia filiale dedicata, ma la versione che è stata distribuita a TEST è stata creata dal mio ramo peer (aveva solo le sue modifiche). Stavo per spingere la mia roba ma non volevo perderla, dato che apprezzo il nostro tempo per il QA e volevo che lui e il mio tester fossero in grado di lavorare contemporaneamente. Così ho sincronizzato il mio ramo con il suo (la ciliegia ha scelto i suoi cambiamenti nel mio, dopo il comune antenato) in modo che fossero presenti sia i suoi sia i miei cambiamenti. Ha funzionato bene. Tuttavia, ha voluto inserire una soluzione di errore il giorno dopo e l'ha fatto fuori dalla propria filiale senza sincronizzarsi con il mio. Indovina cos'è successo: i miei cambiamenti erano spariti dalla build e solo i suoi erano presenti. Inutile dire che questi rami multipli remoti rendono l'integrazione continua (che mi piacerebbe iniziare a fare e che attualmente non è stata fatta), difficile o praticamente impossibile.
Frustrato con tutto questo, ho lavorato su una proposta al mio team su come modificare questa configurazione. La mia idea è di avere una FILIALE REMOTO CONDIVISA DI INTEGRATION in cui ognuno spinga le proprie cose e che sia qualcosa come un ramo di lavoro in corso che tutto può andare avanti finchè compila e supera test (in pratica passa la build). Le build giornaliere di CI potrebbero essere fatte fuori da questo ramo. Poi c'è un ramo di rilascio a cui le cose non sono inserite direttamente ma è selezionato con cura dal Il ramo WIP corrisponde a ciò che vogliamo nel rilascio. Quindi se pensiamo che i cambiamenti di Dev1 andranno nell'immediata prossima versione, ci prendiamo le sue modifiche. Ma l'importante è che ci sia un ramo UNIFIED per tutti gli sviluppatori del team che lavorano sullo stesso progetto e non lavorano nel silo isolato di ognuno. In questo modo, potremmo effettivamente ribattere continuamente le nostre filiali locali con il telecomando condiviso e ottenere le modifiche dei nostri colleghi in tempo utile rispetto a quando diventano parte del master (o della produzione) quando il volume delle modifiche da sincronizzare può rendere vivente il processo di fusione inferno.
Vorrei chiedere informazioni sui pro e contro della mia metodologia proposta rispetto a ciò che il team sta facendo attualmente e viene spiegato sopra. E in generale, con l'idea dell'attuale cultura del rilascio in mente, che forse non rientra nei miei poteri di cambiamento in quanto è influenzata da molti membri dell'organizzazione sopra di me, quale sarebbe la configurazione di lavoro di squadra più efficiente e indolore.