Ci sono esempi di avere 2 numeri di versione di Release per componenti diversi nella stessa immagine monolitica?

Question

Ci sono esempi di avere 2 numeri di versione di Release per componenti diversi nella stessa immagine monolitica?

#1 da (0 voti)

-1

Sono nuovo per un'organizzazione che ha un numero di versione del suo software di visione e un numero di versione diverso per la funzionalità di supporto (dvr, provisioning, ecc.) di quel software di visione. È un codice C lineare - tutto è globale, strettamente accoppiato e i componenti non vengono compilati separatamente. Quindi tutto nella visione della directory ottiene un numero di rilascio - tutto il resto ne riceve un altro. MA È CONSEGNATO COME LO STESSO ESECUTIVO. Il motivo per cui lo fanno è che se devono eseguire una correzione del codice di provisioning, dicono ai propri clienti che stanno solo rilasciando il codice di provisioning - cioè, nessuna modifica al codice di visione. Ma ci sono variabili globali condivise tra questi componenti. Sarebbe molto facile per una modifica in una sezione influenzare negativamente l'altra (cambiare i tempi, introdurre un puntatore nullo, ecc.).

Troverò una tesi secondo cui questa è una pessima pratica - mi chiedo solo quanto sia grave. La mia domanda è: quanto è sbagliato questo? Qualcuno ha visto qualcosa di simile nell'industria? Ci sono dei vantaggi nel fare questo? Personalmente penso che sia una pratica orribile e non vedo alcun beneficio e stanno ingannando i loro clienti ... Ma forse mi manca qualcosa ...

versioning release-management release

posta Redxar 02.04.2018 - 01:33

fonte

1 risposta

Leggi altre domande sui tag versioning release-management release

Fornire caselle di sviluppo per il team Come progettare una comunicazione di oggetti tra 2 software (B2B, così chiamato, comunicazione)?

score 0 · Answer 1

La consegna monolitica può essere eseguita in modo abbastanza sicuro con un controllo qualità appropriato. Rende piuttosto irrilevante il controllo delle versioni dei componenti interni, poiché ciò che viene effettivamente fornito è la combinazione di tutte le versioni interne - purché uno di essi modifichi la combinazione e quindi anche la "versione" del monolite cambi tecnicamente.

Se vuoi, non sarebbe diverso da, diciamo, il codice di una libreria non ottiene una modifica della versione dell'API per ogni codice che ogni modifica riceve: mentre un sistema che usa la libreria potrebbe accettare felicemente il codice aggiornato perché la versione API corrispondente, ciò non significa che ci siano zero possibilità che funzioni ancora come prima (nel bene e nel male).

Indipendentemente dal ragionamento di cui sopra, IMHO non è ancora una buona pratica in quanto può causare confusione, sia internamente che dal lato del cliente. Ad esempio, dire che un cliente segnala un problema per la versione X del software di visione. Per essere certi del contesto della versione monolite, l'assistenza clienti dovrebbe determinare anche la versione di provisioning.

Per quanto riguarda la storia raccontata ai clienti - potrebbe essere validi motivi di business dietro di esso (che possono includere anche ragioni storiche) - dopo tutto, quasi tutto riguarda la percezione in questi giorni.