Controllo del codice sorgente per il team SaaS

0

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.

    
posta Andy 06.02.2017 - 14:19
fonte

2 risposte

2

Il tuo problema riguarda il modo in cui la governance dovrebbe funzionare. Dovresti considerare l'approccio decentralizzato, perché il problema che descrivi si riferisce a molte cose sugli svantaggi di avere il controllo della versione centralizzata. Controllo della versione decentralizzata (spesso chiamato controllo della versione distribuito o DVCS ).

In parole povere, usare DVCS significa:

  • Hai meno preoccupazioni sui blocchi di file, perché ogni dev ha il proprio copia del repository.
  • Puoi lavorare offline.
  • La sincronizzazione può essere eseguita in un secondo momento come unione tra il ramo dopo una richiesta di pull approvata. (ma questo flusso potrebbe non essere il migliore per te)

Ci sono molte migliori implementazioni di modelli decentralizzati, uno dei controlli di versione molto popolari sono Git e Mercurial.

In base alla tua domanda, credo che tu stia utilizzando il modello originale di TFVC, Team Foundation Version Control come archivio centralizzato. Se si utilizza TFS, è consigliabile utilizzare il modello Git in TFS per centralizzare. È supportato molto bene in TFS 2015.

Questa è una buona panoramica del supporto Git di TFS: link

Le distribuzioni attraverso il sito del cliente possono essere semplificate utilizzando il modello di distribuzione nella gestione delle release di TFS, sfruttando Gestione del rilascio di TFS utilizzando le definizioni di rilascio e le porte di approvazione.

In primo luogo è necessario implementare l'integrazione continua (CI), quindi la distribuzione continua mediante la gestione delle versioni implementata come definizioni di rilascio in TFS.

Per maggiori informazioni sulla gestione delle versioni in TFS 2015 (e TFS 2017), visita: link

    
risposta data 14.02.2017 - 08:23
fonte
0

I conflitti sono causati spingendo le singole modifiche in tutti e 3 i rami. Cambiare il sistema di controllo della versione non ti aiuterà a eliminare questi conflitti, nella migliore delle ipotesi potrebbe renderlo un po 'più facile per affrontarli.

Sembra che tu stia operando partendo dal presupposto che ciò che è convalidato e funziona in un ramo - Dev , per esempio - può essere tranquillamente unito a un altro ramo - Testing in questo caso. Il che non è necessariamente vero, dal momento che ci sono stati cambiamenti in Testing che non sono entrati in Dev - esattamente quelli che causano i conflitti di merge - il che rende Testing divergenti da Dev .

In pratica stai sprecando risorse nel tentativo di stabilizzare 3 diversi ambienti anche se ne stai spedendo solo uno.

Il passaggio a una true metodologia CI dovrebbe consentire di ridurre al minimo gli sforzi inutili: disporre di un singolo ramo, scegliere un buon sistema CI, tenere tutti sulla stessa pagina.

Vedi anche Che cosa è la strategia di ramificazione più pulita da utilizzare quando si creano artefatti riutilizzabili?

    
risposta data 31.03.2017 - 05:26
fonte

Leggi altre domande sui tag