Due basi di codice in un repository ... c'è mai una buona ragione per farlo?

0

Lavoro su due basi di codice che sono correlate, ma indipendenti. Uno è scritto in PHP, l'altro è Node JS. Attualmente sono in un unico repository. Il repository è distribuito a Heroku per il codice Node e un diverso provider di hosting per il codice PHP. Non ho impostato il repository, ma ora gestisco le applicazioni.

C'è qualche buona ragione per cui queste basi di codice dovrebbero essere nello stesso repository? Farebbe la differenza se fossero nella stessa lingua?

PS: le basi di codice sono correlate ma non condividono alcuna dipendenza, anche i database utilizzati sono diversi.

    
posta Chris Cirefice 21.11.2017 - 11:59
fonte

1 risposta

1

Il precedente progetto in cui ho lavorato raggruppava molti linguaggi e servizi nello stesso repository e forniva una scatola di Vagrant che dava a questo un ambiente di sviluppo completo.

Ciò significava che tutte le pagine esterne, le API del client, i microservizi interni e così via erano accessibili fin dall'inizio. Ci sono voluti solo due comandi per fare in modo che un nuovo sviluppatore diventasse un insieme di servizi utilizzabili per iniziare a programmare. Come sottolinea Doc Brown nel suo commento, è molto importante la relazione del codice. Tutti i servizi in questa configurazione erano strettamente interconnessi e inutilizzabili l'uno con l'altro. Non è detto che non ci fossero altri motivi per dividere il codice base.

A volte i repository sono decisamente separati. I più grandi motivi per cui riesco a vedere la parte superiore della mia testa;

  • Se vuoi limitare strettamente l'accesso - Forse alcuni utenti non dovrebbero poter accedere ad alcune applicazioni / lingue / codice
  • Diverse persone lavorano sulle diverse basi di codice e non hanno relazioni tra loro
  • La dimensione di una singola lingua / codice base / applicazione è abbastanza grande da giustificarlo
  • Inizi a creare e utilizzare repository di pacchetti interni / esterni - Credo fermamente che dovresti avere un repository per pacchetto / modulo che distribuisci con repository

Detto questo, per la maggior parte dei progetti di sviluppo interni in cui tutti possono o dovrebbero essere in grado di accedere a tutto il codice e non sono necessari processi di implementazione di fantasia, un approccio più rozzo va bene. Nel mio attuale progetto abbiamo diviso il codice front-end e il codice back-end in due repository separati poiché ci sono gruppi distinti che lavorano sui loro lati separati.

Penso che il miglior consiglio che posso dare sia:

Use one repository until you have a reason to divide the code base into multiple repositories, then ask yourself again if you really have a reason to divide it.

Nel tuo caso sembra esserci una ragione per dividere i repository ma se nessuno dei punti sopra elencati è soddisfatto o ti rende incapace di dormire la notte, ti consiglio caldamente di dividere il codice in questo momento.

    
risposta data 21.11.2017 - 12:52
fonte

Leggi altre domande sui tag