I repository non modificati dovrebbero ottenere un numero di versione aggiornato alla fine dello sprint?

2

Diciamo che abbiamo un grande progetto che è diviso tra più repository. Abbiamo qualcosa come

condiviso-funzionalità-repo GUI-repo REST-server-repo sostenendo-quadro-ti-plan a release-separata-repo Comunicazione-biblioteca-per-3-parti-repo ecc ...

Durante una primavera uno di questi repository, forse le comunicazioni di terze parti, non viene toccato e il codice non cambia, ma tutti gli altri repository vengono modificati. Alla fine dello sprint vogliamo concludere e taggare tutto per il rilascio e aggiornare i numeri di versione.

Quale è considerata la migliore pratica per il mio repository non toccato? Da un lato sembra strano dare un nuovo numero di versione, dal momento che nulla è davvero cambiato. D'altra parte abbiamo bisogno / voglio puntare il repository alla versione più recente dei repos è dipende da, che aggiorna il pom. Non aggiornare il numero di versione sembra portare a qualche strano stato incoerente a quel punto. Al momento non aggiorniamo nulla, ma questo finisce con la libreria non toccata, in ultima analisi, usando una vecchia versione di codice perché sta ancora puntando al nostro repository di funzionalità condivise che è 4 sprint vecchi ...

Qual è l'approccio raccomandato per versificare il suo caso?

    
posta dsollen 18.04.2016 - 18:37
fonte

1 risposta

3

Il tuo approccio attuale è corretto. Come hai accennato, vuoi evitare la frammentazione. Mantenendo i numeri di versione coerenti su tutti i repository, è semplice riportare tutto a una versione precedente per qualsiasi motivo. Una volta che inizi a trasportare numeri di versione diversi, hai introdotto un'altra cosa da monitorare.

Un altro modo di guardarlo è chiedere cosa stai perdendo? Una quantità insignificante di byte nei tuoi repository per aggiungere un altro tag, nel caso di Git? Suppongo che se stai utilizzando un diverso sistema di controllo di revisione che mantiene copie separate del codice per le filiali e che tu mantenga un ramo per ogni versione, potresti utilizzare più spazio, ma in questi giorni lo spazio su disco è poco costoso.

La parola "coerenza" è occasionalmente sopravvalutata in questo campo, ma è certamente giustificata in questo caso. Non c'è niente da guadagnare non mantenendo i numeri di release coerenti tra i tuoi repository.

In alternativa, se do vuoi eliminare la sensazione "strana" di cambiare i numeri di versione in reposce dove nulla è cambiato, potresti applicare un approccio che sto attualmente utilizzando per mantenere un repository di integrazione che non ha alcun controllo sui repository da cui trae origine. All'interno di questo repository di integrazione, manteniamo un manifest che punta a tutti i suoi telecomandi e alle loro revisioni utilizzate per ogni versione. La versione di rilascio del repository di integrazione è completamente astratta dalle revisioni del repository remoto. Il manifest è aggiornato ad ogni release. Questo ci consente di ripristinare il nostro repository di integrazione e creare da qualsiasi punto: gli script di build utilizzano il manifest per estrarre dalla corretta revisione dei repository remoti.

Ci sono due punti chiave in questo approccio:

  1. Il manifest è sotto controllo di revisione nel repository di integrazione. Non fare in modo che i consumatori del tuo repository guardino da un'altra parte per queste informazioni in cui potrebbe non essere sincronizzato.
  2. I numeri di release dei repository remoti sono completamente separati dai repository di integrazione. Aggiornare il numero di versione del telecomando per abbinare il repository di integrazione solo quando cambierà sarà confuso - o renderli tutti uguali su ogni versione, o dare loro tutti i numeri di rilascio completamente indipendenti.
risposta data 18.04.2016 - 19:32
fonte

Leggi altre domande sui tag