Messa in scena di artefatti nel server di build?

3

Gli artefatti Java sono spesso messi in scena attraverso diversi "livelli di qualità", chiamati alfa, beta, releaseCandidate, release ecc. Entrano nella fase successiva se hanno superato i test (automatici o manuali).

Abbiamo un vecchio software di gestione temporanea primitivo nella nostra azienda. Questo dovrebbe essere sostituito. Prima di optare per ottenere un software esistente o scrivere qualcosa di nuovo, vogliamo capire meglio l'argomento. La prima domanda per me è: il server di compilazione è il posto giusto per gestire la gestione temporanea?

Il server di build gestisce già una serie di passaggi come compilazione, test delle unità, packaging, ecc. Questi passaggi infine distribuiscono un artefatto al nostro repository aziendale. Implementare la stadiazione significherebbe che dopo quella prima implementazione, il processo verrebbe interrotto e si potrebbero innescare manualmente ulteriori fasi, che di nuovo porterebbero a implementazioni.

O la stadiazione deve essere eseguita in un repository di elementi, spingendo gli artefatti da un sottoregostrario a un altro?

Per essere chiari: la parte a cui sono principalmente interessato è il processo manuale di spingere gli artefatti da uno stadio all'altro, di solito dopo un test manuale. È importante che l'artefatto si trovi già nel deposito degli artefatti prima che entri nello stadio finale, ad es. le versioni beta sono disponibili dal Repository Artifact, ma un manager può promuovere versioni beta per rilasciare versioni.

    
posta J. Fabian Meier 28.04.2017 - 13:13
fonte

1 risposta

-1

Invece di pensare a uno stadio a più livelli, limitalo a due.

  • Release - qualcosa che quando viene inserito nel repository di risorse non dovrebbe cambiare senza avere una nuova versione
  • Istantanea: qualcosa che può cambiare nel tempo o addirittura scomparire (una volta che la versione è stata rilasciata)

Per quanto riguarda la versione, non c'è motivo per cui non puoi avere versioni di rilascio con un suffisso di .Alpha .Beta .Stable

Un sacco di questo lavoro può essere fatto con il plugin di rilascio di Maven (sebbene non sia banale da comprendere e configurare specialmente per i sistemi di controllo delle versioni meno dolorosi)

Detto questo per rispondere alla tua domanda più specifica sull'avere più server. Dipende tutto da te e dalle tue regole. Vorrei raccomandarne uno pubblico o persino usare Maven central se è open source. Sonatype OSS fornisce una buona guida per impostare tutto e io lo uso per i miei progetti.

Tuttavia, ci si trova in una configurazione aziendale, quindi direi un server aziendale per chiunque nell'azienda sia da utilizzare che da consumare e uno di staging. Questo dividerà il carico tra release server e server di staging. Le versioni avranno alpha e cosa no da quando sono rilasciate comunque, a meno che non siano ancora aggiornate, nel qual caso vanno al server snapshot.

E probabilmente ti consiglierei di configurare il server di rilascio per collegarsi come proxy al centralino in modo da poter limitare la quantità di traffico di rete esterno dalla tua azienda.

    
risposta data 28.04.2017 - 22:32
fonte

Leggi altre domande sui tag