Strategia di integrazione continua - Rif. Progetto contro ramificazione/unione

Question

Supponiamo di avere 7 progetti principali in una base di codice legacy (un'API aziendale). Il codice base contiene circa 50 applicazioni che fanno riferimento a uno o più dei progetti principali. Solo un paio delle 50 applicazioni funzionano ancora dopo che una migrazione di vfs a tfs è stata eseguita manualmente. Per far funzionare nuovamente le applicazioni, molte sono state tolte dall'API aziendale e inserite nel proprio progetto TFS.

Sto cercando di convincere i colleghi che dovrebbero non fare un ramo dei progetti di base e mettere la copia in progetti TFS separati e unire solo le aggiunte al progetto nucleo di nuovo nel API impresa dopo un rilascio a PROD. Ovviamente l'integrazione continua sarà molto più difficile quando è meno frequente.

Sto cercando di convincere i colleghi che sarebbe meglio prendere i progetti principali dall'API aziendale e inserirli nel proprio progetto TFS e quindi fare riferimento al bin/debug.

È meglio Branch, copiare i branch per separare i progetti TFS e poi Unisci (e vedere i conflitti alla fine) o è meglio incapsulare progetti core e forzare un team di 20 a usare una sola copia di ciascuno dei progetti principali?

Answer 1

Sono sicuro che volete che i vostri team facciano riferimento ai binari già costruiti delle API di base. La corretta granularità del riuso, è la granularità di rilascio (un accumulo di versione) vedi C di Robert C Martin ++ Relazione 96 e la nostra spiegazione qui: http://www.urbancode.com/html/resources/articles/reuse-maturity-model.html

In sostanza, sembra che le squadre sono in preda al panico e solo facendo la cosa più semplice che potrebbe farli tornare e in grado di consegnare. Questa strada è comprensibile, ma penso che sia meglio se riconoscono che sarebbe meglio avere le loro librerie comuni come una base di codice condivisa e che riutilizzare il codice piuttosto che le DLL è male, e che il debito tecnico deve essere affrontato mentre le cose si stabilizzano .

Answer 2

In realtà dipende dalla maturità del codice condiviso. Direi che c'è tre approcci che si possono seguire, ognuno con i suoi pro e contro:

Opzione 1: Direttamente loro riferimento fuori del proprio team di progetto

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> Application 1 
       --> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> Application 2 
       --> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

Con questo approccio, è possibile impostare in il tuo CI è costruito per far sì che tutte le applicazioni inizino a crescere una volta effettuato il check in in un CoreProject.
si sono tenuti ad avere i progetti di gruppo mappato localmente con un convegno (oppure compilando si romperà)

Questo è un buon approccio se si modifica costantemente il CoreProject & bisogno di quei cambiamenti rapidamente riflessi a tutte le applicazioni colpite.
Implica anche che puoi permetterti instabilità su una determinata App, nel caso in cui un cambiamento in un CoreProject lo possa infliggere.

Opzione 2: Indirettamente farvi riferimento tramite ramificazione

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> SharedSources 
      --> CoreProject1_branch 
       --> CoreProject1.csproj 
     --> Sources 
      --> Application 1 
       ---> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> SharedSources 
      --> CoreProject1_branch 
       --> CoreProject1.csproj 
     --> Sources 
      --> Application 2 
       ---> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

Con questo approccio, ogni volta che il check-in cambiamenti nella CoreProject1, è necessario organizzare un'unione per ogni applicazione interessata. Questo pone un certo impegno, ma ti dà il tempo di stabilizzare il CoreProject nel suo parco giochi e poi unirlo alle tue Apps.
Questo approccio implica che si disponga anche di una definizione di build per ciascun CoreProject.
In generale questo è un buon modo per procedere se si apprezza la stabilità di CoreProject & non può permettersi di "contaminare" le proprie App qualora le modifiche dovessero causare problemi. Questo è l'approccio che abbiamo scelto.

Opzione 3: Fare riferimento al file in ciascuna applicazione

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> SharedBinaries 
      --> CoreProject1_branch 
       --> CoreProject1.dll 
     --> Sources 
      --> Application 1 
       ---> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> SharedBinaries 
      --> CoreProject1_branch 
       --> CoreProject1.dll 
     --> Sources 
      --> Application 2 
       ---> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

Con questo approccio, si 'd bisogno di controllare in uscita binaria di un CoreApplication costruire in ogni applicazione.
Questa opzione è consigliata solo se si è sicuri che CoreApplication è stabile & non è necessario eseguire il debug su base regolare.

In sostanza l'opzione 2 & opzione 3 è simile, separata dal noto dibattito "progetto vs. file di riferimento". Vedere here per una risorsa SO, molto altro può essere recuperato tramite ricerche.

Se i progetti principali sono dovuti a cambiamenti costanti e/o hanno una copertura di prova unitaria bassa, è necessario optare per l'opzione 2 (o 3).
Se siete sicuri della loro qualità, optare per l'opzione 1 è una buona scelta, poiché migliorerà notevolmente la vostra produttività complessiva.

Senza alcuna conoscenza dei vostri prodotti e della loro qualità, basandosi semplicemente sui numeri piuttosto grandi forniti (20 persone, 50 soluzioni, 7 progetti principali), opterei per l'opzione 2/3.

Un altro suggerimento importante: accade più spesso che il progetto condiviso non abbia alcun mezzo di test separati. Se questo è il caso e Core Projects non ha test di unità, nessun piano di test dedicato, non ha senso fare altro che l'opzione 1.

Un'ulteriore grande risorsa in materia è il work dai ranger ALM.