È buona prassi eseguire il check in dei file assemblyinfo.cs aggiornati dopo la compilazione

4

Il nostro processo di compilazione modifica il numero di versione di tutti i file AssemlyInfo.cs, in modo che il numero di versione possa essere gestito completamente dal server di generazione.

In questo momento, commettiamo i file AssemblyInfo.cs modificati dopo la compilazione riuscita. Durante la valutazione di TeamCity, non sono riuscito a trovare un modo per farlo senza usare svn tramite la riga di comando.

Poiché TeamCity fornisce molte impostazioni relative al controllo della versione (ad esempio, la gestione delle credenziali di accesso, etichettatura), mi chiedo perché non ci siano opzioni come "checkin changes after build" o qualcosa del genere.

Quindi è buona pratica impegnare i file assemblyinfo.cs aggiornati dopo la generazione sul build server? Quali sono i pro e i contro?

    
posta JanDotNet 27.09.2016 - 10:03
fonte

1 risposta

6

Uno dei grandi rischi che consente al tuo server di compilare modifiche al controllo della versione è che è molto facile creare un ciclo di feedback non desiderato.

Spesso è desiderabile che un commit to (trunk of) del controllo di versione attivi automaticamente una build sul build server. Tuttavia, se anche lo stesso build server esegue il commit delle modifiche, si innescherebbe continuamente da solo.

Poiché normalmente il build server modifica solo i metadati relativi alla build (data di compilazione, numero di versione, ecc.), la soluzione comune è lasciare che il build server generi il file con tali informazioni prima di avviare il processo di compilazione effettivo.
Se il file contiene informazioni aggiuntive oltre a ciò che può essere generato dal build server, il sistema di controllo della versione può contenere un modello per AssemblyInfo.cs in cui il build server deve solo sostituire / compilare le informazioni sulla versione / build corrette. Per le build locali, puoi aggiungere una fase di pre-build per compilare il modello con le informazioni di build che identificano la build come build locale.

Usando un tale file modello, il contenuto statico e modificato manualmente di AssemblyInfo.cs è ben controllato in versione, ma non si ottengono infinite modifiche di revisione su quel file per ogni esecuzione del sistema di generazione.

    
risposta data 27.09.2016 - 10:38
fonte

Leggi altre domande sui tag