È consigliabile mantenere progetti separati nello stesso repository se sono strettamente correlati?

Question

Sono nelle fasi iniziali di un'applicazione Web che conterrà un'applicazione JavaScript lato client distribuita sul browser del client e un'API REST di tipo server che risiederà sul mio server. I due comunicheranno usando i dati Ajax e JSON.

Ora ecco la cosa; vengono sviluppati completamente separatamente, non condividendo nemmeno una riga di codice o una risorsa. Entrambe sono le applicazioni node.js. Il lato server usa express e sequelize per tutto il lato server, e il lato client è sviluppato usando il server di sviluppo hem con stylus e coffee-script e verrà compilato in 3 file (index.html, application.js e application.css) che verrà in definitiva distribuito dal server come dati statici.

La parte sono incerto su come controllare la versione. Dovrebbero avere numeri di versione condivisi o separati, per esempio. Inoltre, come dovrebbe apparire il repository git. È comune che una cartella root del repository git contenga due o più cartelle con progetti separati ma strettamente correlati? O dovrei separarli per branch, uno chiamato server, uno chiamato client? O dovrei dividerli in due repository separati? (Questo sarebbe più costoso in quanto utilizzo repository privati ​​github)

Non sto cercando nessuno che mi dica cosa fare, ma mi informi dei pro e contro delle alternative. Nella tua esperienza quale sarebbe la migliore linea d'azione e perché. Non esitare a suggerire altri corsi d'azione se ritieni che siano buoni.

Grazie!

Answer 1

La regola generale è che "le cose che cambiano allo stesso tempo dovrebbero essere messe in versione insieme".

Se il back-end deve supportare più client e cambierà indipendentemente dal proprio frontend, come sarebbe se si stesse cercando un'architettura basata sui servizi, vale la pena di pensare a separare queste cose in progetti separati.

Tuttavia, poiché sembra che questi due progetti siano accoppiati abbastanza strettamente e la tua applicazione web abbia senso solo con entrambi, ti suggerisco di iniziare a tenerli nello stesso repository. È un'esperienza di sviluppo a basso impatto e puoi sempre dividerli in un secondo momento se diventa doloroso o se i team separati devono lavorare su di essi.

Answer 2

Dal mio punto di vista vorrei dividere client e server in due cartelle principali sotto root. Ci sono diversi motivi:

1. Le versioni client e server si correlano (fisicamente) tra loro. Come fanno comunque, il tuo cliente sarà fortemente correlato all'api fornito dal tuo software server. Quindi, se si codifica il repository come release, si sarà sicuri che entrambi gli artefatti funzionino insieme senza intoppi.

2. Avrete meno problemi a implementare pesanti test di integrazione e a implementare un'infrastruttura di integrazione continua. Con le altre opzioni è anche possibile metterlo in atto, ma dovrai fornire altro overhead.

Generale utilizzo ramo:

• il maestro di solito è usato come un coerente "istantanea" stabile della domanda (compresi client, server)
• un ramo può essere utilizzato per rappresentare una nuova sviluppo di funzionalità. Di solito sono usati in questo modo. Quindi potresti finire con i rami 1..n contenenti aggiunte al tuo software. Che sarà riunito al tuo padrone se ti senti felice con esso.

Answer 3

rami sono per fare versioni parallele di una comune base di codice (vedi "When should you branch").
Quindi non è una buona idea tenere traccia di due diversi, ma strettamente correlati, moduli.

Le semplici directory all'interno del repository Git saranno sufficienti e garantiranno che qualsiasi tag impostato su tale repository faccia riferimento a entrambi i moduli.