Qual è l'approccio corretto di Subversion quando si usa la DLL

In effetti qualcosa non va.

Ci sono due approcci per organizzare lo sviluppo di qualcosa di diviso in moduli:

1. Separato e asincrono: la versione di ogni DLL separatamente e tratta il resto dei moduli in modo simile ai componenti di terze parti. In questo caso ogni DLL dovrebbe fare una sorta di rilascio per fornire la sua funzionalità agli utenti (altri sviluppatori). Ciò includerà la pubblicazione della versione "rilasciata" della DLL sul repository di controllo di origine o sul repository di artefact.
2. Combinato e sincrono: tutte le DLL sono sviluppate insieme e rilasciate (quando necessario) insieme, in questo caso dovresti pensare ad accelerare il processo di costruzione. Questo può essere fatto in modo simile all'ottimizzazione di un programma: trova il più grande fattore di rallentamento ed eliminalo.

La selezione tra questi due approcci è di solito basata sul grado di accoppiamento tra di loro. Se la maggior parte delle modifiche tocca più DLL o le modifiche in DLL diverse dipendono l'una dall'altra, probabilmente l'approccio 2 è più appropriato. Se ogni DLL ha un'interfaccia stabile, uno scopo chiaro e specifico e un qualche tipo di compatibilità tra le versioni, può essere applicabile l'approccio n. 1.

Hai chiaramente bisogno di un membro del team dedicato che abbia il compito di aggiornare il codice alla testa ogni volta che qualcuno esegue un cambiamento, e crea anche una compilazione completa e pulita ogni notte e copia le dll prodotte ogni volta per una posizione centrale in cui gli altri membri del team possono prendere le DLL.

Purtroppo questo è un compito laborioso e noioso.

Fortunatamente puoi ottenere un computer per farlo per te!

Sono chiamati server di Continuous Integration e sono progettati proprio per questo: prendi il codice ogni commit, costruiscilo e "archivia" i risultati da qualche parte. Il mio preferito è Jenkins. Può inserire le DLL risultanti in SVN o copiarle in una condivisione di rete (si consiglia di inserire solo le DLL rilasciate in SVN, le build giornaliere o su richiesta sono troppo transitori per essere conservate a lungo). Può anche inviare via email a tutti per dire che una build ha avuto esito negativo (uno sviluppatore ha dimenticato di aggiungere un file che era necessario ad esempio) e può anche mostrare un dashboard con lo stato di ogni build.

Non penso che sia una buona idea avere un ramo puramente per eseguibili e DLL.

I file eseguibili e le DLL dovrebbero essere un prodotto del ramo master di costruzione sul server di generazione.

Il build server costruirà il ramo, eseguirà i test (se ce ne sono) e archivierà gli assembly compilati da qualche parte sulla rete. Ogni volta che è necessaria la distribuzione, si prenderanno gli artefatti compilati dalla posizione di rete e verranno implementati nell'ambiente pertinente.

Non vuoi creare DLL localmente e poi caricarle da qualche parte. Cosa succede se si costruisce su una macchina a 32 bit e quindi si prova a distribuire su una macchina a 64 bit? Lo stesso vale per la condivisione di artefatti compilati tra gli sviluppatori.

Nel mio precedente lavoro abbiamo avuto un problema in cui la compilazione completa (con tutti i test di unità e integrazione) richiedeva poco meno di un'ora per essere eseguita (presupponendo che nulla fallisse, che è un'ipotesi rischiosa da fare). Ora non è possibile per il team di 20 sviluppatori eseguire una build ciascuno, potenzialmente sprecando 20 ore di sviluppo. Quello che abbiamo deciso di fare è costruire tutti i file eseguibili e le DLL su un server di build e poi distribuirli al team attraverso NuGet.

Devono esserci due rami efficaci.

1. Il ramo di sviluppo, che contiene il codice solo . Ci si aspetta che gli sviluppatori siano in grado di compilare il codice per produrre le DLL.
2. Il ramo di rilascio. Che contiene solo i file eseguibili e le DLL.

Nel mezzo, durante la notte, è possibile utilizzare un server di integrazione continua per creare la versione più recente e impegnare le DLL / Exe ecc. al ramo di rilascio e contrassegnare tali elementi con un numero di versione / versione.

Il ramo di rilascio non richiede di essere SVN. ma puoi farlo se lo desideri. Significa che le persone possono trovare rapidamente le revisioni precedenti.

La mia opinione personale è che ogni sviluppatore dovrebbe essere in grado di sedersi, sincronizzare il capo del ramo di sviluppo, essere in grado di compilare il sorgente ed eseguirlo. Se questo non è possibile, è necessario rendere possibile. O fissando la struttura del progetto, o fornendo delle DLL binarie di codice che gli sviluppatori non dovrebbero ricompilare. (libreria DLL ecc.)