Come mantieni i binari rilasciati sotto il controllo della versione? Questo permette di tracciare quali cose vengono cambiate tra ogni versione. Intendo separare i binari rilasciati dal repository sorgente. I binari rilasciati sono costruiti dal software di integrazione continua o compilati manualmente.
Due opzioni:
a) No. Assicurati solo di avere build deterministici riproducibili, ovvero costruire la stessa revisione del controllo sorgente con la stessa configurazione produce sempre lo stesso binario.
b) Designare una directory da qualche parte come fonte autorevole per le build pubblicate. Fai caricare i binari parte della procedura di distribuzione / spedizione e assicurati che la directory di pubblicazione pubblicata sia coperta dal tuo piano di backup. Non hai bisogno di alcun controllo di versione qui; le build sono write-once, se hai bisogno di cambiare qualcosa, fai una nuova build.
In ogni caso, i binari e altri output di build non appartengono al controllo del codice sorgente, per numerose ragioni.
Utilizzare un repository di risorse per i binari, non un sistema di controllo della versione. Una versione specifica di un binario rilasciato non dovrebbe cambiare nel tempo, quindi il controllo della versione non ha senso poiché i file non cambierebbero.
Vedi ad esempio repository Maven come repository per archiviare / pubblicare / offrire versioni e altri 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 tu stesso) o li stai impegnando troppe volte (solo commit quando è pronto per la spedizione, non ogni volta che lo costruisci).
La maggior parte dei binari delta SCM abbastanza bene, abbiamo usato per mettere una DLL di risorse 2Mb nel nostro SVN e ogni volta sarebbe delta a qualche kb.
Ho sentito molti argomenti che gli SCM sono per la fonte, non i binari, ma questo è chiaramente falso se si considera che la maggior parte del software consiste di immagini, anche se si tratta solo di file di icone. Sono binari, ma fanno parte della fonte, quindi inseriscili e non essere così dogmatico al riguardo. Sento anche che puoi ricostruire il file binario quando necessario, spesso è il caso, ma può essere un enorme dispendio di tempo per i sistemi meno recenti che non sono più supportati attivamente. Se devi ricreare un sistema con solo service pack o patch precedenti per corrispondere al sistema utilizzato per costruire un binario 3 anni fa, sarai felice di aver aggiunto il cestino al tuo SCM.
L'unica volta che devi preoccuparti di aggiungere build al tuo SCM è se lo stai facendo automaticamente come parte del processo del build server - non farlo. Riempi il tuo SCM con build che non hanno alcun beneficio per te. Invece, aggiungili solo quando vengono rilasciati. In questo modo sai esattamente cosa ha il tuo cliente e puoi riprodurre tutti i problemi segnalati dai clienti con i binari che stanno utilizzando, e non quelli che hai ricostruito (usando, diciamo, gli ultimi aggiornamenti al compilatore o al sistema operativo).
Non conservo i binari di rilascio sotto il controllo della versione. Invece li pubblico in una posizione ben definita in modo che altri strumenti li ispezioni e li utilizzi. Lavoro molto in Java, quindi significa che pubblico Jars su 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, taggavo o etichettavo le versioni nel mio sistema di controllo della versione con il numero di versione della versione. Ma questo è solo per tracciare i file sorgente, non i binari. I binari sono artefatti della build e non è necessario che siano sotto controllo di versione.
La soluzione migliore è utilizzare in modo esclusivo il tuo sistema di CI per tutte le build significative dal punto di vista organizzativo (rilasci, release candidate ecc ...).
Questo collega sistematicamente i binari rilasciati al contenuto del repository senza dover effettivamente archiviare i binari nel repository.
Ad esempio, se si utilizza SVN, utilizzare lo schema organizzativo del ramo principale; fai tutto lo sviluppo giorno per giorno in / trunk e crea un tag / per ogni versione una volta che è pronta.
Configura il tuo sistema di CI per costruire da tag e da trunk, e falla scrivere in output su una directory di rete la cui struttura rispecchia la struttura di livello superiore del repository:
Il sistema di compilazione dovrà trattare la directory / builds / trunk / come un buffer circolare, memorizzando le ultime n build, cancellando le vecchie build come vanno.
La directory / builds / tags / , d'altra parte, è un archivio permanente. Gli artefatti di build sono memorizzati in directory con nomi generati secondo lo schema seguente:
dove [rev] è l'ID revisione SVN, [data] è la data nel formato YYYYMMDD e [build_id] è un Contatore unico a 3 cifre, incrementato dalla prima build in poi, rendendo ogni directory di costruzione univoca.
Il processo sopra descritto offre i seguenti vantaggi:
Gli artefatti di costruzione sono legati sistematicamente all'origine che li ha generati, quindi puoi trovare facilmente il codice sorgente di un particolare artefatto di costruzione, (e viceversa).
Questo costituisce la base per un'ulteriore automazione del rilascio. Ad esempio, generazione automatica di documenti di rilascio ecc.
Leggi altre domande sui tag version-control release-management