Suggerimenti sulla gestione delle dipendenze per una versione?

Question

Il nostro sistema comprende molti siti Web .NET, librerie di classi e un database MSSQL. Usiamo SVN per il controllo del codice sorgente e TeamCity per creare automaticamente un server di prova.

Il nostro team sta normalmente lavorando su 4 o 5 progetti alla volta. Cerchiamo di moltiplicare molti cambiamenti in un'implementazione più ampia ogni 2-4 settimane.

Il mio problema è tenere traccia di tutte le dipendenze per un'implementazione. Esempio:

sito A non può andare a vivere fino a quando abbiamo srotolato Branch X della biblioteca di classe B, costruito a sua volta contro il tronco di libreria di classi C, che ha bisogno di Config Aggiornamenti Y e Z e Database aggiornamento D, che esigenze di migrazione script e ...

diventa ancora più complesso - come fare in modo progetto di ogni sviluppatore è in realtà compatibile con gli altri e stanno costruendo contro le stesse versioni. Sì, questo è un problema di gestione tanto quanto un problema tecnico.

Attualmente la nostra soluzione non ottimale è:

• una lavagna messa in vendita di caratteristiche che non sono andati in diretta ancora
• basandosi sulla nostra memoria e l'intuizione quando si pianifica l'implementazione, fino siamo abbastanza sicuri abbiamo pensato a tutto ...
• una corsa a secco sul nostro ambiente di Staging. È una buona indicazione, ma spesso non siamo sicuri che Staging sia sincronizzato al 100% con Live - parte del problema che spero di risolvere.
• una certa quantità di alaggio durante il giorno di lancio.

Fin qui tutto bene, meno alcune chiamate ravvicinate. Ma con la crescita del nostro sistema, mi piacerebbe un sistema di gestione dei rilasci più scientifico che consenta una maggiore flessibilità, come la possibilità di implementare una singola modifica o un bugfix in proprio, con la certezza che non infrangerà nient'altro.

Suppongo che la soluzione migliore riguardi una sorta di sistema di numerazione delle versioni e forse uno strumento di gestione dei progetti. Siamo una start-up, quindi non siamo troppo entusiasti di aderire religiosamente a processi rigidi, ma siamo felici di iniziare, a patto che non aggiunga altro overhead di quello che vale.

Mi piacerebbe ricevere consigli dagli altri team che hanno risolto questo problema.

Answer 1

Sembra che tu abbia già un server di integrazione continua, ma non utilizzarlo correttamente. Parte del problema è che non sai quali modifiche finiranno in una versione e quali no.

Presumo che tutti i progetti facciano parte di un progetto che comprende, per il quale esiste un repository di controllo di origine. Come prima misura, dovresti provare a separare il codice in fase di sviluppo rispetto a codice rilasciato stabile/to-be nelle filiali. Imposta Teamcity per creare regolarmente una build completa del ramo stabile. Se una serie di modifiche è pronta per il rilascio, il creatore del cambiamento dovrebbe essere responsabile della fusione, insieme a tutte le dipendenze, nel ramo stabile. CI ti dirà se tutto è andato liscio o no. È l'idea di CI che sei "sempre pronto per il rilascio".

Hai detto che ci sono diversi progetti su cui il tuo team sta lavorando costantemente e che hanno alcune interdipendenze.Questo mi rende un po 'sospettoso:

• Se i progetti sono interdipendenti, perché sono separati? Anche se si evolvono a velocità diverse, hanno davvero bisogno di essere separati?
• Avete di conseguenza repository diversi per ogni progetto? Questo renderà il rilascio davvero difficile.
• Le dipendenze possono essere gestite a livello binario? O ci sono delle dipendenze nel tempo di compilazione?

Nella mia esperienza, è sempre più facile gestire le dipendenze a livello binario (è sufficiente aggiornare una libreria nel progetto). D'altra parte, non ho mai avuto la situazione in cui i progetti non correlati dipendono dalla stessa dll (che è un'applicazione in sé e non solo una libreria di utilità o qualcosa del genere). In questo caso, è più facile gestire le dipendenze a livello di origine.

Alla fine, un pensiero casuale: se si usasse un sistema di controllo delle versioni distribuito (come git o mercurial), avere tutto il codice nello stesso repository sarebbe molto facile. Ogni progetto può avere il proprio ramo, che viene regolarmente aggiornato con le ultime modifiche dal ramo principale (integrazione diretta). Al termine di una modifica, il ramo del progetto viene reimmesso nel ramo principale (integrazione inversa). Il team di Windows in Microsoft ha elaborato questo flusso di lavoro.