Come migliorare il nostro processo di controllo del codice sorgente

Question

Come migliorare il nostro processo di controllo del codice sorgente

#1 da (6 voti)

3

Sfondo:

Stiamo utilizzando una gestione agile del progetto e seguiamo gli sprint per lo sviluppo. Stiamo utilizzando un singolo repository in bitbucket.org che utilizza mercurial. Il repository ospita 3-4 prodotti. Ci sono molti progetti con 4 soluzioni per ogni prodotto. Ci sono alcuni progetti specifici per il prodotto e alcuni progetti condivisi.

Non possiamo fare cambiamenti nella struttura delle cartelle, visto che abbiamo già un server di team city che sta facendo build automatizzati che funzionano bene. Ma sono aperto se è davvero fondamentale per gestirlo.

Processo corrente
Il nostro processo attuale può essere descritto come segue:

durante lo sviluppo, usiamo hgFlow start e finish features (develop branch)
per le versioni, iniziamo i rilasci, li rendiamo stabili, finiamo i rilasci (il nuovo ramo di sviluppo da sviluppare)
per hotfix iniziamo l'hotfix (una nuova hotfix dal ramo di rilascio) e la finiamo (si fondono per lo sviluppo e l'impostazione predefinita)

Problemi
Ecco alcuni dei problemi con questo processo:

quando iniziamo il rilascio, ci sono altri 3 codici di prodotto che non sono pronti per essere rilasciati, è presente anche nel rilascio e al termine del rilascio, passa all'impostazione predefinita indesiderata.
quando cambiamo progetti condivisi in fase di sviluppo, influisce sulle versioni aperte e dobbiamo correggerle
quando cambiamo progetti condivisi in release, influisce sui prodotti precedentemente rilasciati

ci sono così tanti altri problemi tecnici che abbiamo scoperto e abbiamo immediatamente smesso di usare hgFlow, e proprio ora facendo la cartella manualmente diff per avviare / finire il rilascio e gli hotfix.

Alcune delle opzioni che ho pensato

Crea un singolo repository per ospitare il codice sorgente di ciascun prodotto eccetto il prodotto condiviso
Crea un singolo repository per ciascun progetto condiviso
Mantenere separatamente HgFlow e tag ecc.

Questo è troppo lavoro, ad esempio, quando voglio iniziare il rilascio, devo andare al prodotto e ad ogni progetto condiviso interessato per iniziare una nuova versione. Lo stesso vale per lo sviluppo regolare, per una singola funzione, se voglio cambiare prodotto e progetto condiviso, devo creare funzionalità in tutti i progetti.

Come gestirlo meglio?

Aggiornamento - 9 feb 2016 I nostri prodotti sono basati su .net, stiamo usando bitbucket per l'hosting, il mercurial e l'albero dei sorgenti con HgFlow per le operazioni di sviluppo.

version-control branching mercurial agile

posta Prashant Lakhlani 08.02.2016 - 09:10

fonte

1 risposta

Leggi altre domande sui tag version-control branching mercurial agile

L'Entity Framework di Microsoft è una variante proprietaria di NHibernate? Esiste un termine per le funzioni che iniziano con il prefisso "Is"?

score 6 · Accepted Answer

Configurare un repository nuget a livello aziendale. (Sto assumendo .NET dalla terminologia che stai usando, ma ci sono equivalenti per quasi tutti i framework linguistici.) O creane uno sul tuo server , o utilizza un servizio come myget , o semplicemente usa il tuo feed nuget incorporati nel serverTeamCity .

Distribuisci il tuo codice comune nei pacchetti su quel repository, come una build completamente diversa in TeamCity. Quindi, assumendo il semplice scenario delle soluzioni A e B con codice comune nel progetto P - il progetto P viene rimosso dalla Soluzione A e B e trasferito nella propria Soluzione, che crea uno o più pacchetti di nuget.

Questi pacchetti di nuget sono inclusi come riferimenti in qualsiasi progetto che ne abbia bisogno. Proprio come i pacchetti da un server pubblico di nuget, tranne che devi dire a Visual Studio dove si trova il tuo server dei pacchetti.

Ora puoi gestire le tue filiali in un repository Mercurial a livello di progetto, indipendentemente. Il processo di rilascio del codice nel progetto comune è:

Repository P

Avvia funzione
Apporta modifiche
Funzionalità finale
Avvia versione
Aumenta versione
Crea
Deploy
Fine rilascio

Repository A

Avvia funzione
Aggiorna pacchetto
Funzionalità finale
Avvia versione
Aumenta versione
Crea
Deploy
Fine rilascio

(Per la cronaca, sembra che tu stia ampiamente utilizzando hgflow, anche se non stai utilizzando le scorciatoie da riga di comando, quindi sto usando questa terminologia qui.)

Ti sembrano tanti passaggi? È. Ma sono tutti piccoli passi. Una volta che lo hai fatto per un po ', diventa una specie di seconda natura.

E, soprattutto, noterai che non hai ancora influenzato la soluzione B. Va bene. Il tuo più grande problema è stato risolto. Il collega può continuare a sviluppare la soluzione B senza disegnare accidentalmente le modifiche. Quando uno di voi è pronto, è possibile aggiornare il pacchetto nella soluzione B.

Se utilizzi versioni beta (ad esempio 4.0.1-beta01) per codice non testato, il tuo collega non accidentalmente inserirà una modifica che non hai ancora testato (o come ci piace chiamarlo, un bug) .

Questo processo non è senza costi però.

In particolare, devi stare attento alle dipendenze di nuget. Più hai, più pesante è il processo per apportare modifiche al progetto di livello inferiore. Meglio avere più progetti o progetti più grandi di più dipendenze.