CI / CD e processo di controllo del codice sorgente utilizzando Git e VSTS

1

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

  1. 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.
  2. La compilazione avviene sul nostro server di generazione locale, utilizzando un agente di generazione che guarda VSTS.
  3. È testato ecc. in quanto viene promosso attraverso gli ambienti, supponendo che i test ecc. passino
  4. 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.

    
posta David C 15.05.2017 - 15:09
fonte

1 risposta

1

Un prerequisito per l'implementazione / distribuzione continua è l'integrazione continua, ovvero l'intero team che unifica le modifiche su un singolo ramo centralizzato più volte al giorno. Sembra che questo sia esattamente quello che stai facendo sul ramo di sviluppo, quindi la cosa che mi sembra strana è qual è il punto del ramo principale? La cosa che sembra fare è:

  • tenere traccia di ciò che è in produzione (cosa che puoi fare con i tag)
  • puoi diramarti dal master se hai bisogno della produzione di hotfix (in git puoi ramificarti da qualsiasi commit / tag)

Quello che hai descritto del tuo deploy / processo di test sembra buono, quindi mi piacerebbe rinominare lo sviluppo per masterizzare ed eliminare master.

    
risposta data 23.12.2017 - 10:41
fonte