Come gestire il controllo della versione aziendale? [duplicare]

Question

Come gestire il controllo della versione aziendale? [duplicare]

#1 da (1 voti)

1

Esistono standard di settore o best practice su come gestire una base di codice in rapida evoluzione?

I tipi di applicazioni che sto sviluppando hanno sempre un aspetto personalizzato. Quindi ci sarà sempre del codice scritto che è specifico del cliente per ogni progetto.

Il metodo che stiamo usando ora è il seguente:

Diversi progetti "CORE" sono isolati l'uno dall'altro, ogni progetto principale è una libreria di classi che è in grado di funzionare da solo o con dipendenze da altri moduli core.

Tutti questi moduli core sono documentati (Sandcastle) e pacchetti NuGet creati per loro, che vengono offerti tramite un feed NuGet privato.

Quando un cliente acquista il software, creiamo un progetto specifico per il cliente che implementa il codice su misura che richiedono e carica i pacchetti NuGet dalle librerie principali, se necessario. La creazione di questo progetto è ciò che viene fornito al cliente e ogni progetto del cliente ha il proprio repository Git.

Questo ha funzionato bene per circa un anno, ma credo che aggiungendo funzionalità alle librerie di base il numero di pacchetti di nuget stia crescendo abbastanza rapidamente.

Esiste un metodo migliore per organizzare il codice, assicurandosi che non ci sia una versione separata dello stesso codice in giro?

So in questo post StackOverflow che afferma che:

Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository.

Ma questo sembra che ci crei problemi, a causa di dispiegamenti su misura.

Qualche idea o commento su ciò che sto facendo male?

Modifica

I problemi che prevedo di seguire con Google sono principalmente relativi alla gestione dei rilasci e alla creazione di problemi. Utilizziamo l'integrazione continua, in modo che ogni commit di una build venga attivato e il test venga eseguito automaticamente. Se usiamo un repository onnicomprensivo, non sono sicuro di quale sarà l'effetto sul build e sui server di test. Dovrà costruire ogni progetto dei clienti?

O ci sarebbe una filiale per cliente? In questo caso è meglio di un repo per cliente?

language-agnostic version-control project-management release-management

posta Nick Williams 08.05.2014 - 10:38

fonte

1 risposta

Leggi altre domande sui tag language-agnostic version-control project-management release-management

Vantaggi della memorizzazione nella cache del conteggio degli elementi in una struttura dati rispetto al calcolo su richiesta? Come costruire una rappresentazione cubica del cubo di un rubik, dato un array

score 1 · Answer 1

Questo è più un problema di gestione del codice. Al centro di tutto ciò, è necessario fare una distinzione tra codice comune e modifiche su misura. Una volta che puoi rispondere a questo, il problema SCM andrà a posto facilmente.

Ad esempio, è possibile avere tutte le impostazioni dell'applicazione per utilizzare molta configurazione. Per tutte le funzionalità del cliente, si aggiunge un'opzione di configurazione e si implementa la funzione nella base di codice comune. Un cliente acquista quindi una singola applicazione e un file di configurazione appositamente creato (o DB o qualsiasi altra cosa).

In alternativa, hai una base di codice comune che estendi con classi ereditate per ogni caratteristica del cliente. Lo SCM verrebbe utilizzato per il checkout della base di codice comune e invariabile e quindi porterà i nuovi file da aggiungere alla build per quel cliente.

Oppure puoi provare a ramificarti da un tronco centrale e modificare il codice secondo necessità per ogni cliente, con eventuali correzioni al tronco comune che vengono unite in ogni singolo ramo del cliente. Quest'ultimo è più facile per gli sviluppatori, ma un vero dolore per il gestore di build.

Direi che probabilmente stai facendo le cose a posto con un ampio set di librerie comuni, ma forse il tuo codice comune è troppo complesso. Prova a combinarli in un numero inferiore di librerie, non importa se il cliente ha un extra che non usano mai in un unico pacchetto. Ad esempio, potresti essere in grado di cavartela con un singolo pacchetto Nuget che estrae una singola libreria con tutti i codici comuni, ad esempio.