Abbiamo TFS 2013 solo per il controllo della versione, Team City per la costruzione, un server Nuget e Visual Studio 2013. Poco tempo fa, ma non abbiamo impostato le linee guida per ottenere il codice dallo sviluppo in un processo di build e di gestione dei pacchetti. Git-Flow come mostrato di seguito funzionerà per la maggior parte dei nostri progetti (ad esempio, abbiamo bisogno di una sola linea di sviluppo). Non siamo forzati in TFS, ma mi piacerebbe vedere se GitFlow può funzionare anche con TFS ( note : non molta esperienza precedente con TFS invece Git). Con TFS 2013+ unire un ramo come release dovrebbe essere possibile in master ? C'era una restrizione (credo) con il TFS pre-2013 che la fusione delle filiali fosse possibile solo fino alla sua origine (cioè sviluppo nel caso release ).
Dovremmo essere in grado di consentire a TeamCity di gestire la gestione dei pacchetti Nuget quando una versione ( nota : una versione semantica, link ) cambia (ovvero le bolle rotonde sulle linee master e sviluppo ). Qualcuno ha fatto questo?
Quando lavori su una funzione , release o hotfix è responsabilità del team di sviluppo impostare la versione corretta nell'assembly . Solo noi possiamo sapere se c'è un cambiamento maggiore, minore o di patch. Quindi solo noi possiamo aggiornare le informazioni sull'assembly. Ciò detto quando il codice viene controllato in master o development TFS aumenterà automaticamente il set di modifiche (penso per collezione). Per gestire le unioni in sviluppo o master che richiedono una nuova versione, le persone con TFS utilizzano le richieste pull (se hanno l'aggiornamento 4 o lo sono solo se il codice è gestito da Git )? Altrimenti, c'è il rischio che i numeri di versione non vengano impostati correttamente.
La mia domanda principale è in che modo le persone gestiscono le versioni di bump in TFS e un costruttore come Team City in un momento successivo a pompare un pacchetto NuGet? Con un po 'di amministrazione eccessiva?
