Distingue tra istantanee e versioni ufficiali, mentre distribuisci esattamente ciò che è stato testato

Naviga le tue risposte
4

Supponiamo che la seguente situazione:

  1. Un server CI ha generato artefatti di istantanee regolari
  2. Ad un certo punto, un artefatto è considerato "stabile" e viene assegnato al controllo qualità per il test
    1. Se passa, viene distribuito come versione ufficiale
    2. Se non passa, una nuova istantanea viene testata fino a quando non si passa

Dato un build arbitrario, vogliamo essere in grado di verificare se questa build è una versione ufficiale o meno.

Supponiamo anche che le macchine del cliente non siano connesse a Internet, quindi non c'è modo di interrogare un database con informazioni sulla versione o controllare un server delle licenze.

Ora, una regola è quella di rilasciare esattamente ciò che è stato testato , che esclude il patch binario delle risorse o la ricompilazione in un "rilascio" di sapore.

Esiste un flusso di lavoro che soddisfa tutti questi vincoli?

    
posta Julius Bullinger 03.02.2017 - 09:16
fonte

3 risposte

3

Firma crittograficamente una release, ma non una release candidate / snapshot.

Il codice potrebbe verificare se il proprio pacchetto ha una firma valida, se la firma sul pacchetto è mancante o non valida, quindi mostrare il numero rc, altrimenti se la firma è valida il numero rc non viene mostrato.

    
risposta data 07.02.2017 - 02:05
fonte
3

Questo è il flusso di lavoro "standard" nella mia esperienza.

  • funzionalità nuove funzionalità di diramazione
  • quando "dev complete" si fondono per lo sviluppo
  • ci si basa sullo sviluppo e assegna il numero di versione incrementale (no -RC)
  • build auto distribuito su qa (l'artefatto va al polpo)
  • test dei tester
  • risolti uniti in dev
  • test pass
  • Unisci per padroneggiare
  • distribuisci la versione approvata promossa per la vita
  • rollback (joke)

Quindi no. Dato solo un artefatto casuale al di fuori del flusso di lavoro, non puoi dire se ha superato il test o meno.

Ciò che protegge gli utenti dall'esecuzione del codice RC è il processo di distribuzione stesso.

Ora, se stai sviluppando un software desktop, non puoi costringere semplicemente gli utenti a effettuare l'aggiornamento. Quindi se stai distribuendo il software Beta hai ragione, devi ricostruire o ripristinare la versione RC finale per ottenere numeri di versione non beta ecc.

Ma diciamo che decidi di ricostruire. Ora potresti introdurre bug perché, non è lo stesso binario vero?

Ma! Stai andando a testare quel binario comunque? quindi quello che hai veramente è DUE flussi di lavoro di rilascio. Uno per beta e uno per rilasci di produzione. Una build beta non è mai una build di produzione e viceversa.

    
risposta data 03.02.2017 - 19:11
fonte
1

Given an arbitrary build, we want to be able to verify whether this build is a snapshot or an official release.

Bene, dalla tua descrizione tutte le build sono istantanee (create nel passaggio 1) ma solo alcune sono ufficialmente rilasciate (nel passaggio 2.1), quindi suppongo vuoi solo sapere se è una versione ufficiale o meno:)

Un possibile approccio sarebbe basato su criteri:

  • In un ambiente cliente, anche se non hai accesso a un DB di rilascio, la risposta dovrebbe sempre essere una versione ufficiale (il codice non obbligatorio non dovrebbe mai arrivare al cliente; persino esegui il bombardamento o limitati ad accedervi nel passaggio 2.2 per impedire l'implementazione accidentale).

  • Nel proprio ambiente, dovrebbe essere in grado di cercare l'ID della versione istantanea nel database di rilascio e ottenere la risposta.

risposta data 04.02.2017 - 06:33
fonte

Leggi altre domande sui tag

Come gestire i metodi equivalenti di simulazione senza rendere i test fragili? Rapporti nell'architettura dei microservizi