Come si mantengono i binari rilasciati sotto il controllo della versione?

Come si mantengono i binari rilasciati sotto il controllo della versione? Ciò consente di tenere traccia di quali elementi sono cambiati tra ogni versione. Intendo separare i file binari rilasciati dal repository di origine. I file binari rilasciati sono creati dal software di integrazione continua o compilati manualmente.

Due opzioni:

a) No. Assicurati solo di avere build deterministiche riproducibili, ovvero costruire la stessa revisione del controllo del codice sorgente con la stessa configurazione produce sempre lo stesso binario esatto.

b) Designare una directory da qualche parte come fonte autorevole per build pubblicate. Rendi il caricamento dei file binari parte della procedura di distribuzione / spedizione e assicurati che la directory di build pubblicata sia coperta dal tuo piano di backup. Non è necessario alcun controllo di versione qui; le build sono in scrittura singola, se è necessario modificare qualcosa, si crea una nuova build.

In entrambi i casi, i binari e altri output di generazione non appartengono al controllo del codice sorgente, per numerosi motivi.

Utilizzare un repository di artefatti per i file binari, non un sistema di controllo della versione. Una versione specifica di un file binario rilasciato non dovrebbe cambiare nel tempo, quindi il controllo della versione non ha senso poiché i file non cambieranno.

Vedi ad esempio i repository Maven come repository per archiviare / pubblicare / offrire rilasci e altri file binari (ad es. Come documentazione)

Inseriscili. Non c'è problema, a meno che tu non stia usando git (che non unisce bene i binari, quindi dovrai gestirli da solo) o li commetti troppe volte (commetti solo quando è pronto per la spedizione, non tutte le volte che lo costruisci).

La maggior parte dei binari delta SCM abbastanza bene, abbiamo usato per inserire una dll di risorse da 2 Mb nel nostro SVN e ogni volta deltava a qualche kb.

Ho sentito molti argomenti secondo cui gli SCM sono per il sorgente, non per i binari, ma questo è chiaramente falso se si considera che la maggior parte dei software è costituita da immagini, anche se sono solo file icona. Sono binari, ma fanno parte della fonte, quindi inseriscili e non essere così dogmatico al riguardo. Ho anche sentito che puoi semplicemente ricostruire il binario quando necessario, spesso è così, ma può essere un enorme sforzo di perdita di tempo per i sistemi più vecchi che non sono più attivamente supportati. Se devi ricreare un sistema con solo service pack o patch più vecchi per corrispondere al sistema che è stato usato per costruire un binario 3 anni fa, sarai contento di aver aggiunto il cestino a SCM allora.

L'unica volta che devi preoccuparti di aggiungere build al tuo SCM è se lo stai facendo automaticamente come parte del processo del server build - non farlo. Riempirai il tuo SCM con build che non hanno alcun vantaggio per te. Invece aggiungili solo quando vengono rilasciati. In questo modo sai esattamente cosa ha il tuo cliente e puoi riprodurre qualsiasi problema segnalato dai clienti con i binari che stanno usando e non quelli che hai ricostruito (usando, diciamo, gli ultimi aggiornamenti del compilatore o del sistema operativo).

Non tengo i binari di rilascio sotto controllo di versione. Invece li pubblico in una posizione ben definita in modo che altri strumenti, ispezionarli e usarli. Faccio molto lavoro in Java, quindi ciò significa che pubblico Jars nei repository Maven locali. Tuttavia, non utilizzo questi strumenti per tenere traccia di ciò che è cambiato per versione. Dopotutto, sono binari e non c'è molto altro da tracciare oltre al conteggio dei file.

Per tenere traccia delle modifiche tra le versioni, contrassegnerei o etichetterei le versioni nel mio sistema di controllo della versione con il numero di versione della versione. Ma questo è davvero solo per tracciare i file sorgente, non i binari. I binari sono artefatti della build e non devono essere sotto il controllo della versione.

La soluzione migliore è utilizzare in modo esclusivo il tuo sistema CI per tutte le build significative dal punto di vista organizzativo (release, release candidate ecc ...).

Ciò collega sistematicamente i file binari rilasciati al contenuto del repository senza dover effettivamente archiviare i binari nel repository.

Ad esempio, se si utilizza SVN, utilizzare lo schema organizzativo delle filiali principali; fare tutto lo sviluppo quotidiano in / trunk e creare un tag / per ogni versione una volta pronta.

Configura il tuo sistema CI per compilare dai tag e dal trunk e farlo scrivere in una directory di rete la cui struttura rispecchia la struttura di livello superiore del repository:

• / Costruisce / trunk / [giro] [data] [ID build] /
• / Costruisce / tag / release_0_1_3beta4 / [giro] [data] [ID build] /

Il sistema di compilazione dovrà trattare la directory / builds / trunk / come un buffer circolare, memorizzando le ultime n build, eliminando le build precedenti mentre procede.

La directory / builds / tags / , d'altra parte, è un archivio permanente. Gli artefatti di compilazione stessi sono archiviati in directory con nomi generati secondo il seguente schema:

• [Rev] [data] [ID build]

dove [rev] è l'ID di revisione SVN, [data] è la data nel formato AAAAMMGG e [build_id] è un contatore univoco a 3 cifre, che aumenta dal primo build in poi, rendendo unica ogni directory di build.

La procedura sopra descritta offre i seguenti vantaggi:

1. Gli artefatti da costruire sono legati sistematicamente alla fonte che li ha generati, quindi puoi trovare facilmente l'origine di un particolare artefatto da costruzione (e viceversa).

2. Ciò costituisce la base per un'ulteriore automazione del rilascio. Ad esempio, generazione automatica di documenti di rilascio ecc ...