Consigli: sviluppo di due progetti in cui uno è un'estensione dell'altro

6

I due progetti

Lavoro in una piccola azienda di software e attualmente mi trovo in una situazione in cui sono al termine dello sviluppo per "Progetto A", in procinto di avviare lo sviluppo per "Progetto B". Il Progetto B dovrebbe essere una "estensione" del Progetto A (entrambi sono principalmente app web).

Nel Progetto B, il piano è non solo aggiungere nuove funzionalità, ma modificare alcune delle cose esistenti dal Progetto A; per esempio, alcune delle pagine web. La difficoltà è che vogliamo ancora poter distribuire il Progetto A, senza nessuna delle caratteristiche del Progetto B, ma con eventuali correzioni di bug "A" che finiamo mentre facciamo il lavoro "B".

Metodo 1: ramificazione

Il modo in cui sto pensando è che il Progetto A è come il ramo "stabile" e il Progetto B è come il ramo "dev", ma "dev" non viene mai riunito in "stabile". Siamo preoccupati di questo approccio perché sembra che richiederà molta disciplina per garantire che le modifiche alla correzione dei bug vengano sempre applicate al ramo A del progetto e quindi unite al ramo B del progetto (a differenza delle correzioni implementate su il ramo del Progetto B e la necessità di copiarli manualmente nel ramo Progetto A).

Metodo 2: Architettura plugin

In alternativa, potremmo iniziare a trasformare le cose in una sorta di "plug-in" ovunque ci sia bisogno di essere una "differenza" tra il Progetto A e B. In questo modo sembra anche che potrebbe trasformarsi in un disordine aggrovigliato, dal momento che non siamo ancora sapere esattamente quali cambiamenti saranno necessari.

La scelta

In questo momento, lo vedo come una scelta tra il minore dei due mali (leggi 'difficoltà'). In base alla tua esperienza, hai qualche consiglio che ti aiuterà con la mia scelta? Ci sono altri modi per gestire la divisione tra i due progetti che potrei aver trascurato?

    
posta Dylan Halperin 04.01.2013 - 19:47
fonte

3 risposte

5

Indipendentemente dallo SCM utilizzato, il metodo basato su Branch è più veloce nell'implementazione, più semplice nella gestione e semplicemente migliore , specialmente se seguirai il flusso di lavoro "Branch per task"

  • "Il progetto A" è un ramo a lungo termine
  • "Progetto B" è anche un ramo a lungo termine, creato in un momento dal "Progetto A"
  • Ogni attività (funzionalità o bugfix o ...) è un ramo a breve termine separato, che, dopo aver terminato, può essere (deve essere) unito in uno o più target
risposta data 04.01.2013 - 20:09
fonte
3

Una strategia di ramificazione per le versioni sarebbe probabilmente la migliore in uno scenario come questo. Certo, richiede disciplina, ma anche molti aspetti dello sviluppo del software.

Ecco una strategia di esempio per darti alcune idee (nonostante il nome ... non è veramente SCM specifico, ma contiene alcune informazioni utili per DVCS).

Un'architettura di plugin si applicherebbe davvero solo se i plug-in fossero parte della funzionalità dell'applicazione (qualcosa come l'architettura di Drupal). Hanno il loro posto, ma il loro posto non è la versione del progetto.

    
risposta data 04.01.2013 - 20:12
fonte
2

Per il tuo scenario Metodo 2, la soluzione basata su Plugin sembra migliore. Sarà penoso rendere il codice modulare ed estensibile per la prima volta, ma lo si è fatto con successo, e un ulteriore sviluppo sarà più facile.

Se prevedi di utilizzare il Metodo 2, prima di tutto devi indicare chiaramente lo scopo di entrambe le app e capire il terreno comune e come può essere tutto biforcato in moduli diversi. Essere molto chiari sulla definizione dei limiti per i moduli in base al loro scopo, come se fatto correttamente può velocizzare il tuo sviluppo.

    
risposta data 04.01.2013 - 19:57
fonte