Supponiamo di avere il progetto A e il progetto B, dove il progetto B dipende dal progetto A - diciamo che A è una libreria. E il progetto A e il progetto B vivono in repository di controllo di versioni separate, perché il progetto A è stato creato da una terza parte o perché hai deciso di organizzare i repository in quel modo. Vuoi apportare alcune modifiche al progetto B, ma per fare ciò devi apportare alcune modifiche al progetto A. Quindi fai due richieste pull, una per le modifiche al progetto B e una per le modifiche al progetto A - queste I PR devono "essere applicati insieme - sebbene nella pratica , ovviamente, uno di questi deve essere prima unito (logicamente, deve essere il PR per il progetto A) ed ecco dove il problema può entra.
Abbiamo impostato il nostro server CI (TeamCity) per creare tutte le filiali di funzionalità, in modo da poter vedere facilmente se una PR individuale o autonoma per la proiezione B interrompe le cose nel progetto B. Ma perché il codice nei rami di funzionalità non viene pubblicato al nostro repository di artefatti (Nexus) fino a quando non viene unito al master, questo non funziona molto bene per coppie (o anche catene) di PR come lo scenario descritto sopra. Possiamo solo vedere, in modo valido, se il PR per il progetto B verrà costruito sul server di build dopo che abbiamo già unito il PR per il progetto A. E recentemente è successo che questa build dipendente non è riuscita ... a causa di un problema che si è verificato solo sul build server.
Quindi, ci siamo ritrovati in una situazione in cui il master del progetto B non stava crescendo a causa di una coppia di PR strettamente vincolata solo a metà fusione: il PR per il progetto A era stato unito, ma il PR per il progetto B non aveva 'stato ancora, a causa del problema inaspettato sul server di build.
Come potremmo modificare il nostro flusso di lavoro per evitare questo tipo di problema in futuro?