Come funziona lo sviluppo mainline / trunkd quando abbiamo più versioni in prod allo stesso tempo?

1

Anch'io non sono uno sviluppatore quindi ti prego di sopportare me. Stiamo fornendo soluzioni per diversi clienti ed è normale che si verifichi una situazione del genere:

  • Il nostro cliente ha una versione 1.1 e vuole che forniamo manutenzione e supporto per questa versione
  • Allo stesso tempo, ci chiedono di sviluppare un'altra versione (diciamo 1.2) anche con nuove funzionalità, che verranno pilotate in campo (quindi entrambe le versioni saranno in produzione allo stesso tempo).

Come può funzionare questo sviluppo mainline, non c'è solo una linea principale e per esempio le correzioni fatte su 1.1 (in supporto) devono essere anche fuse in 1.2. ma non il contrario con le caratteristiche.
Il motivo per cui lo chiedo è che il nostro superiore ha sentito che agile, CI, CD ecc. È la cosa e che dobbiamo farlo.

    
posta Ezoela Vacca 23.07.2018 - 13:06
fonte

3 risposte

0

Hai chiarito in commenti :

Well basically, this is the situation we have: one version is in production and needs continuous support, another version in the pilot (also needs support). And our management now pushes for trunk-based development.

Lo sviluppo basato su trunk ha tutto il lavoro in corso sul trunk. Ci possono essere lavori nei rami, ma questi non vengono mai reinseriti nel bagagliaio. Nel tempo, V1.1 e V1.2 divergeranno.

Vedi il seguente confronto pittorico da trunkbaseddevelopment.com :

Se è possibile predisporre la codifica delle funzionalità alle interfacce, le modifiche dal trunk possono essere più facilmente adattate al ramo. Altrimenti, stai essenzialmente mantenendo 2 basi di codice dal momento della divisione.

    
risposta data 24.07.2018 - 18:04
fonte
0

In teoria non è così. La caratteristica che definisce questo tipo di flusso è che distribuisci sempre le nuove funzionalità immediatamente. Mentre è necessario NOT per implementare le funzionalità.

Tuttavia, avendo detto che non ci sarebbe nulla che ti impedisse di ramificarti da una particolare versione, dire v1, fare correzioni su di esso e distribuire da quel ramo ai tuoi clienti v1.

Di nuovo, in teoria potresti unire nuovamente il tuo ramo v1 al master per ottenere le correzioni di bug in v2 e successivi. Ma in pratica penso che scoprirai che le versioni divergono molto rapidamente e sarà più semplice scrivere la correzione una volta per versione.

    
risposta data 23.07.2018 - 13:15
fonte
0

Quello che stai cercando è chiamato rilascio . Esiste naturalmente per i software desktop e mobili, in cui ogni dispositivo ha la propria copia di un programma. È meno comune per il software web, perché dovrebbe essere unico. Ma puoi fare lo stesso per l'applicazione web: configurare un server link e impostare il ramo di rilascio v1.1 per distribuirlo, e configura un server link e crea il ramo di rilascio v1.2 distribuito lì.

Esistono diversi modi per gestire i rami di rilascio. Mi piacciono questi 2 link: modello basato su thunk , altri modelli . Sono supponenti, ma hanno delle belle foto in modo che tu possa scegliere la strada.

    
risposta data 23.07.2018 - 13:29
fonte

Leggi altre domande sui tag