Il modello Spotify è diventato un esempio popolare per il modo giusto di fare sviluppo .
Se un prodotto ha un repository di codice singolo, principale, come la maggior parte dei prodotti, come fai a rendere le squadre autonome e indipendenti?
C'è un codice comune su cui diverse squadre lavoreranno nello stesso periodo e se una squadra aggiunge un bug, durante il rilascio, il codice di tutte le squadre verrà ripristinato, quindi tutte le squadre saranno influenzate.
Non ho familiarità con il modello Spotify, ma guardando l'articolo a cui ti sei collegato sembra che la chiave per rispondere alla tua domanda si trovi nella porzione Rilasci disaccoppiati (enfasi sulla mia) .
Decoupled Releases
Instead of creating cumbersome rules and processes to manage their releases, Spotify simplified the process to encourage small and frequent releases. They changed the architecture to enable decoupled releases using the encoded embedded framework. Each section of the web browser is like a frame of a website where each Squad can release their own stuff directly. They have three different Squads based on the self-service model.
- Feature Squad: Focused on one feature area.
- Client App Squad: Focused on making the release easy in one specific area of the platform.
- Infrastructure Squad: Focused on making other Squads more effective by providing tools and routines for Squads.
Organizzando in questo modo, il "codice comune" che menzioni è ridotto al minimo, se non eliminato del tutto. Il codice registrato di una squadra dovrebbe avere poco o nessun impatto sul codice di un'altra squadra.
Non credo che Spotify abbia reso pubblica la sua strategia di ramificazione, ma possiamo parlare in generale di come funzionano le diverse strategie di ramificazione.
Molte applicazioni non hanno una singola filiale nel loro repository di codice. I due approcci più comuni che ho visto è un dev > test > approccio principale, o più comunemente ora, feature branch. Nel secondo caso, una squadra prende un ramo fuori dal main, lavora su una funzione, quindi la unisce nuovamente mentre completano il lavoro, in modo che non entrino in conflitto con altri team.
Detto questo, ci sono persone che sostengono un singolo ramo "principale" che tutti controllano tutto il giorno. Ciò richiede disciplina, ma non è così difficile da lavorare. Volete una buona copertura di test del vostro codice e la gente dovrebbe assicurarsi di inserire il codice più recente e assicurarsi che tutti i test passino prima di eseguire il commit. Inoltre, non appena una build fallisce, la priorità è massima finché non viene riparata. L'unico posto in cui ho visto i team hanno problemi con questo è dove è difficile dire se hai infranto un'altra parte del codice o dove i membri del team non sono abbastanza disciplinati e commettono il codice e se ne vanno senza assicurarti che costruisca e test passi .
Leggi altre domande sui tag release-management agile scrum