Come posso eseguire la produzione come le distribuzioni utilizzando un server artefatto che impone il controllo delle versioni semantiche con artefatti che non hanno ancora ricevuto una versione?

0

Solo un po 'di background. In questo momento i tag del mio team rilasciano i candidati nel controllo della versione. Ho imparato che questa potrebbe non essere la cosa migliore da fare perché dobbiamo ancora passare attraverso i test di accettazione degli utenti prima di rilasciare realmente qualsiasi applicazione è stata taggata. Così ora sappiamo che etichettare i candidati per il rilascio non è la cosa migliore, ma fornisce qualcosa di utile. Mi permette di tenere traccia del file binario che è stato il risultato di quella build che è quel tag. Quindi, se qualcuno inserisce un tag chiamato 1.2.0, allora so di prelevare 1.2.0 quando distribuisco nell'ambiente che usiamo per UAT. Quindi se questo supera il test, utilizzeremo 1.2.0 per la distribuzione in produzione.

Voglio spingerci a utilizzare una strategia di ramificazione invece di distinguere i candidati al rilascio, dalle modifiche che stanno attualmente ricevendo test di accettazione da parte degli utenti, dalle modifiche attualmente in produzione. E in più ho imparato che i tag non dovrebbero apparire fino a quando non avremo condotto UAT e ha superato il QA. Ma il server artefatto da noi implementato richiede che gli artefatti siano archiviati in base ai numeri di versione. Quindi a questo punto, dovremo trovare un modo diverso di implementare le cose nel nostro ambiente di test interno, che non voglio fare. Voglio mantenere il modo in cui distribuiamo le applicazioni il più possibile simili al modo in cui distribuiamo in produzione.

Qualcuno ha mai incontrato una situazione come questa? Oppure sarò costretto a implementare i nostri server UAT in un modo e poi a distribuirli nei nostri server di produzione in un modo diverso?

    
posta arjabbar 23.10.2017 - 19:56
fonte

1 risposta

1

Se stai ancora lavorando su 1.2.0, puoi taggare i tuoi build di release candidate come 1.2.0-RC.123 , '123' è un identificatore univoco (hash di commit, numero di build, timestamp, ecc.) che semplifica il riferimento .

Una volta eseguito il QA e approvato e implementato, puoi taggarlo con la versione "ufficiale", 1.2.0 o 1.2.0-RELEASE .

È facile ripulire i vecchi tag se non ne hai più bisogno. Se stai usando git, qualcosa di simile al seguente:

git tag | grep '${pattern}' | xargs -n 1 -I% git push origin :refs/tags/% (remoto)

e / o

git tag | grep '${pattern}' | xargs -n 1 -I% git tag -d % (locale)

Puoi derivarne e automatizzare molto se usi git-flow come rami di rilascio nel formato: release/1.2.0 .

    
risposta data 01.02.2018 - 12:25
fonte