Il nostro team sta sperimentando alcuni problemi di crescita per quanto riguarda il controllo del codice sorgente. Usiamo Team Foundation poiché si integra facilmente con la nostra infrastruttura esistente, ma sono decisamente aperti ad altre opzioni. Forniamo un servizio software a più di 15 clienti molto diversi che richiedono aggiornamenti costanti del codice. Al momento, abbiamo 3 filiali: sviluppo, test e produzione. I maggiori problemi che abbiamo sono la fusione tra lo sviluppo - > Test e test - > Produzione.
Il nostro codice è in realtà una rappresentazione di oggetti di business condivisi o esclusivi per singoli clienti. Poiché molti dei codici sottostanti nel nostro servizio sono condivisi tra molti client su molte versioni differenti, aggiorniamo costantemente il nostro codice per tenere conto di un elenco infinito di scenari in continua evoluzione. Normalmente i nostri clienti richiedono una modifica e la modifica viene implementata in produzione in tale settimana, pertanto abbiamo distribuzioni di produzione più volte ogni settimana tra i clienti.
Spesso incontriamo conflitti di unione in cui due persone hanno effettuato aggiornamenti allo stesso file nel ramo di sviluppo o di test e questo in genere ci obbliga a unire manualmente il file in Test o da Test in produzione. Sfortunatamente, semplicemente imporre il blocco dei check-out e impedire a due sviluppatori di verificare e lavorare sullo stesso file non è un'opzione per noi perché creerebbe solo ulteriori ritardi e sprecherà più tempo, il contrario di ciò che stiamo cercando di fare. Siamo fiduciosi che un altro team abbia riscontrato problemi simili e trovato un nuovo modo per superare questo problema, quindi ci piacerebbe ricevere un feedback su cosa possiamo fare per migliorare la gestione del codice e il ciclo di vita dello sviluppo con un impatto minimo sui nostri clienti e, soprattutto, il nostro processo aziendale esistente.
Non siamo in grado di operare in base a sprint, pietre miliari o in un ciclo di rilascio programmato perché la natura della nostra attività richiede aggiornamenti per soddisfare le esigenze mutevoli dei nostri clienti (di giorno in giorno). Comprendiamo che questa metodologia potrebbe infrangere molte regole stabilite quando si tratta di best practice di ingegneria del software, ma la maggior parte di questo è dettata dalla natura della nostra attività. Siamo un'organizzazione di grande successo e il nostro metodo attuale funziona, abbiamo pensato che dovremmo ricercare se esistono altri metodi per il nostro modello unico.