Stiamo provando a far funzionare il nostro CI / CD e ho avuto qualche feedback su di esso.
Stiamo utilizzando VSTS e stiamo costruendo applicazioni c # api + JavaScript.
Vogliamo utilizzare la gestione di build e release di VSTS. La gestione del rilascio utilizza l'idea di "promozione" della stessa build attraverso i vari ambienti.
Il nostro processo
- Tendiamo a utilizzare i rami di funzionalità, che vengono poi riuniti per lo sviluppo quando sono abbastanza buoni. Quindi il nostro elemento di configurazione, rileva le modifiche al ramo di sviluppo, attiva una build e gli elementi creati vengono utilizzati per il rilascio.
- La compilazione avviene sul nostro server di generazione locale, utilizzando un agente di generazione che guarda VSTS.
- È testato ecc. in quanto viene promosso attraverso gli ambienti, supponendo che i test ecc. passino
- Poi, quando è stata approvata definitivamente la produzione (per approvazione), vogliamo che aggiorni il controllo del codice unendoci in tag master + con la versione distribuita in produzione. Quindi questo significa che la git merge è gestita da un passo in ritardo nella gestione delle versioni.
In primo luogo, è una configurazione decente per il nostro avvio su CI / CD? Qualche suggerimento per migliorarlo? In particolare il modo in cui la parte di controllo del codice sorgente è, ma vogliamo renderne ogni aspetto migliore.
Dovremmo unirmi al master in precedenza, e quindi creare solo il nostro CI / CD? E utilizzare tag o qualcosa che denoti le versioni che hanno reso la produzione?
Grazie.
Nota: Impossibile trovare un tag per VSTS.