Qual è il modo migliore per eseguire la versione di un progetto multicomponente

Ho un programma che è composto da 5 componenti principali. Trovo che la numerazione della versione standard sia troppo limitante perché vorrei vedere a quale versione si trova ciascun componente.

Qualcuno ha trovato un modo semplice per farlo oltre a elencarli separatamente?

Abbiamo lo stesso identico problema con il nostro prodotto e abbiamo deciso di creare numeri di versione individuali per ciascun componente e la versione del prodotto è solo una versione di marketing che è composta dai vari componenti in una revisione specifica.

Abbiamo una "versione di sistema", che è un numero di versione standard che descrive una particolare configurazione di componenti, quindi un file separato elenca le versioni dei singoli componenti per quella particolare versione di sistema. I clienti dicono 5.2.1 ma possiamo cercare la build individuale se necessario. Di solito per una versione principale sincronizziamo tutte le singole versioni in modo che tutto venga di nuovo creato dallo stesso numero di filiale.

Il controllo delle versioni è un problema separato dallo sviluppo di applicazioni basate su componenti. O si desidera eseguire la versione di ciascun componente oppure si desidera eseguire la versione dell'intera applicazione.

Un modello ben noto per il controllo delle versioni è di Microsoft :

major version.minor version.build number.revision

Ad esempio, puoi vedere i file DLL nella piattaforma .NET per avere versioni come 2.0.3600.1 o qualcosa del genere.

Pertanto, ti consiglio di determinare innanzitutto se desideri eseguire la versione dell'intero sistema o dei suoi componenti. Se si desidera eseguire la versione dell'intero sistema, dopo ogni integrazione, compilare l'intero progetto e aumentare la parte del numero di build . In caso contrario, semplicemente versione ogni componente sulla build.

Fai attenzione al controllo delle versioni, potrebbe ucciderti :-) Non cercare di rendere le cose troppo complicate.

Penso che il seguente approccio possa aiutarti:

Versione ogni componente singolarmente con qualsiasi schema di versioning desiderato. Dai tuoi commenti ho capito che hai un VCS in atto. Suppongo anche che ogni componente abbia un file in cui è conservata la sua versione (giusto?). Una volta al giorno / settimana (a seconda di quale funziona meglio per il tuo team) aggiungi un tag a una delle revisioni più recenti in VCS che contrassegna quella revisione come l'ultima revisione ufficiale (e facoltativamente incrementa un numero di super-revisione). Ora puoi interrogare il VCS per le revisioni con quel tag e quindi cercare la versione dei componenti in quella build ufficiale.

Se vuoi solo localmente, scrivi un piccolo script che aggregherà la versione di ciascun componente dal punto in cui è memorizzato nel codice.

Se vuoi renderlo ancora più elaborato, una volta effettuata la codifica puoi guardare i file appartenenti a ciascun componente, considerando che puoi identificare i file che appartengono a un componente specifico. Se modificato, incrementa la versione per quel componente specifico. L'alternativa è farlo manualmente. Un'altra alternativa è una combinazione di diramazione e fusione con il monitoraggio della versione.

La maggior parte dei numeri di versione utilizza una revisione maggiore e minore guidata dal marketing, quindi non è possibile utilizzarli per tenere traccia delle versioni dei singoli componenti. In breve, è necessario trovare un'altra parte della versione che è possibile utilizzare per tenere traccia delle versioni dei singoli componenti e riservare i numeri di versione maggiore e minore per il monitoraggio dell'intero pacchetto.

Se stai seguendo qualcosa di simile al modello Microsoft:

major-version.minor-version.build-number.revision

È possibile utilizzare .revision per tenere traccia della versione di ogni singolo componente e utilizzare i numeri di revisione minori e principali per tenere traccia di una modifica completa del prodotto, nel solito modo.

Se stai seguendo un modello simile a questo:

Major-Version.Minor-Version.Build-Number

Dovrai utilizzare il numero di build per tenere traccia delle versioni dei singoli componenti.

Libri interi sono scritti sul software di versioning.

Ecco un approccio che io uso.

Ogni parte ha una versione nella forma:

major.minor.developmental

Ognuno di questi è un numero, a partire da 0.

Per un rilascio formale (cioè per i clienti), la parte relativa allo sviluppo deve sempre essere 0 come una questione di politica.

Major è incrementato dalla decisione di marketing.

Il minore viene incrementato dal rilascio di set di funzionalità sul mercato.

Esempio:

• Inizio lo sviluppo su un nuovo componente, quindi il mio numero di versione sarà 0.0.1. Quando rilascio la mia scrivania ai miei colleghi, ad esempio, per i test interni, il numero di sviluppo sale a 0,0,2, 0,0,3 e così via.

• Rilascio sul mercato questa nuova cosa come 1.0.0, in cui l'unica modifica consentita dalla fine dello sviluppo alla versione era la modifica del numero di versione (ad es. 0.0.43 -> 1.0.0).

• Alcune nuove funzionalità devono essere aggiunte. Inizio a lavorare sulla linea di base 1.0.0, aggiungendo queste funzionalità, quindi le versioni che rilascio ai miei colleghi per i test sono 1.0.1, 1.0.2 e così via.

• Le prossime funzionalità verranno rilasciate sul mercato come 1.1.0.

• Il marketing decide che la prossima grande novità sarà davvero grande, quindi uscirà come 2.0.0. Inizio a lavorare su 1.1.1, passando a 1.1.xe rilascio come 2.0.0.

E così il ciclo si ripete.

Questo approccio, per ogni componente, offre la tracciabilità degli antenati.

Interno al tuo sistema di gestione delle revisioni di origine (e oggetto), usa rami e tag (etichette, qualunque sia la tua terminologia del giorno) per gestire lo sviluppo.

Il controllo di revisione può quindi gestire ciascun componente completamente separatamente, con rami di sviluppo ed etichette / tag per ciascuno. Oppure puoi raggrupparli tutti insieme, nel qual caso potresti voler ramificare per pacchetto di lavoro - ma assicurati di etichettare / etichettare per rilascio di ciascun componente (e quando lo fai, etichettare / etichettare tutto, non solo i bit per il componente. In questo modo hai un'istantanea dello stato di tutto al momento.)

È probabile che il processo di rilascio richieda un'attenta valutazione. L'uso di questo approccio include alcuni passaggi manuali e ciò può essere indesiderabile, tutto dipende da come il sistema di generazione inserisce i numeri di versione nell'oggetto finale. Per gran parte del codice incorporato in cui i numeri di versione sono solo numeri con nome (ad es. # Definito nel codice C), hai poca scelta ma comunque fare tutto manualmente. Le piattaforme desktop con belle GUI rendono spesso tutto molto più amichevole.

Sommario

Per me, l'unico modo affidabile per il software versione è utilizzare l' hash o l'identificatore del changeset dal tuo sistema di controllo della versione.

Un numero di versione di build complessivo può essere utile, ma è garantito che sia univoco solo se si dispone di un server di build e / o si firma ogni versione. Per molti di noi, tuttavia, questo semplicemente non è praticabile.

Se il progetto è suddiviso su più repository di controllo versione, sarà inoltre necessario creare un meccanismo in base al quale l'interfaccia utente può eseguire query su ciascun repository dipendente e riportare l'hash all'utente.

Esempio per esperienza personale

In un progetto presso un precedente datore di lavoro, in cui avevamo problemi con il nostro software (interno) di modifica del cliente e la sua ricompilazione, ho istituito un processo in base al quale gli hash mercuriali venivano compilati in ogni applicazione e libreria. Ogni volta che il software veniva avviato, veniva creata una stringa di revisione interrogando tutti i componenti del software.

Questa stringa di revisione è stata visualizzata quando si è passati alla pagina about ed è stata scritta nel file di registro ogni volta che è stata avviata l'applicazione. Era della forma:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

Da ciò ho potuto facilmente vedere che avevano modificato Library3 e non avevano eseguito il commit di tali modifiche nel repository, quindi stanno usando codice che non è controllato. Potrei anche confrontare gli hash con il mio attuale sistema di test, quindi potrei essere in grado di identificare che hanno ripristinato (diciamo) Library1 a una versione precedente.

Ciò significava che ogni volta che segnalavano un bug, potevo sempre ricostruire esattamente il codice in uso al momento in cui si verificava il problema, o almeno sapere con certezza che non potevo riprodurre l'installazione.

Per maggiori dettagli sul sistema di compilazione che ho usato, su come ho realizzato questo, quali problemi ho avuto e cosa le persone hanno suggerito di evitarli, dai un'occhiata alla mia domanda Stack Overflow .

Nota: questo sistema è realmente praticabile solo se si utilizza un sistema di controllo di revisione in cui un determinato hash è garantito per generare lo stesso set di file nella directory di lavoro (ad esempio git e mercurial) se una determinata directory di lavoro può contenere una combinazione di file e le directory di diverse revisioni (es. svn), quindi tutte le scommesse sono disattivate per quanto riguarda lo stato della directory di lavoro e questo metodo non funzionerà affatto.