Migliorare il processo di creazione

Question

Oppure, stabilire effettivamente un processo di creazione quando non ce n'è molto in atto con cui cominciare.

Attualmente, questa è più o meno la situazione che il mio gruppo deve affrontare.Ci occupiamo principalmente dello sviluppo di app Web (ma al momento non dello sviluppo desktop).Le distribuzioni del software sono brutte e ingombranti anche con le nostre app modeste e abbiamo riscontrato troppi problemi nei due anni in cui ho fatto parte di questo team (e azienda).È giunto il momento di fare qualcosa al riguardo, e il risultato è che saremo in grado di prendere due piccioni di Joel Test con una fava (build giornaliere e build in un solo passaggio, nessuna delle quali esiste in qualsiasi forma).

Quello che cerco qui è una visione generale sul tipo di cose che devo fare o a cui devo pensare, da parte di persone che sono state nello sviluppo di software per più tempo di me e hanno anche cervelli più grandi.Sono fiducioso che sarà la maggior parte delle persone che attualmente postano nella beta.

Strumenti rilevanti:Visual Build Source Safe 6.0 (lo so, ma non posso fare nulla sul fatto che usiamo o meno la sicurezza della fonte in questo momento.Quella potrebbe essere la prossima battaglia che combatterò.)

A titolo provvisorio, ho un progetto Visual Build che fa questo:

1. Ottieni l'origine e inseriscila nella directory locale, incluse le DLL necessarie per il progetto.
2. Ottieni i file di configurazione e rinominali secondo necessità (li memorizziamo in una sottodirectory speciale che non fa parte dell'applicazione vera e propria e vengono nominati in base all'uso).
3. Crea utilizzando Visual Studio
4. Precompilare utilizzando la riga di comando, copiando in quella che sarà una directory "build".
5. Copia a destinazione.
6. Ottieni tutte le risorse aggiuntive necessarie, principalmente cose come documenti, immagini e report associati al progetto (e inseriti nella directory dal passaggio 5).C'è molta di questa roba e non volevo includerla in precedenza.Tuttavia, copierò solo gli elementi modificati, quindi forse è irrilevante.Non ero sicuro di voler davvero includere queste cose nei passaggi precedenti.

Devo ancora convincere a disconnettermi da Visual Build per tutto questo, ma non sono ancora al punto in cui devo farlo ancora.

Qualcuno ha qualche consiglio o suggerimento da dare?Noterò che al momento non stiamo utilizzando un progetto di distribuzione.Presumo che rimuoverebbe alcuni dei passaggi necessari in questa build (come lo scambio di web.config).

Answer 1

Quando si intraprende un progetto che non ha mai avuto un processo di creazione automatizzato, è più semplice procedere per gradi.Non cercare di ingoiare troppo in una volta, altrimenti potresti sentirti opprimente.

1. Per prima cosa compila il codice in un solo passaggio utilizzando un programma di compilazione automatizzato (ad es.nant/msbuild).Non ho intenzione di discutere quale sia il migliore.Trovane uno che ti faccia sentire a tuo agio e usalo.Avere gli script di compilazione in diretta con il progetto nel controllo del codice sorgente.
2. Scopri come desideri che venga attivata la build automatizzata.Che si tratti di collegarlo a CruiseControl o di eseguire un'attività di creazione notturna utilizzando le Attività pianificate.CruiseControl o TeamCity sono probabilmente la scelta migliore per questo, perché includono molti strumenti che puoi utilizzare per rendere questo passaggio più semplice.CruiseControl è gratuito e TeamCity è gratuito fino a un punto in cui potresti doverlo pagare a seconda della grandezza del progetto.
3. Ok, a questo punto ti sentirai abbastanza a tuo agio con gli strumenti.Ora sei pronto per aggiungere più attività in base a ciò che desideri fare per test, distribuzione, ecc.

Spero che questo ti aiuti.

Answer 2

Ho una serie di script Powershell che fanno tutto questo per me.

Copione 1:Build: questo è semplice, è gestito principalmente da una chiamata a msbuild e crea anche gli script del mio database.

Copione 2:Pacchetto - Questo richiede vari argomenti per impacchettare una versione per vari ambienti, come test, e sottoinsiemi dell'ambiente di produzione, che consiste di molte macchine.

Copione 3:Distribuisci: viene eseguito su ogni singola macchina dall'interno della cartella creata dallo script Package (lo script Deploy viene copiato come parte del pacchetto)

Dallo script di distribuzione, eseguo controlli di integrità su cose come il nome della macchina in modo che le cose non vengano distribuite accidentalmente nel posto sbagliato.

Per i file web.config, utilizzo il file

<appSettings file="Local.config">

funzionalità per avere sostituzioni già presenti sulle macchine di produzione e sono di sola lettura in modo che non vengano sovrascritte accidentalmente.I file Local.config non vengono archiviati e non è necessario eseguire alcun cambio di file in fase di compilazione.

[Modifica] L'equivalente di appSettings file= per una sezione di configurazione è configSource="Local.config"

Answer 3

Siamo passati dall'utilizzo di uno script Perl a MSBuild due anni fa e non abbiamo più guardato indietro.È possibile creare soluzioni di Visual Studio semplicemente specificandole nel file xml principale.

Per qualcosa di più complicato (ottenere il codice sorgente, eseguire unit test, creare pacchetti di installazione, distribuire siti Web) puoi semplicemente creare una nuova classe in .net derivante da Compito che sovrascrive la funzione Esegui e quindi fai riferimento a questa dal file xml di build.

C'è una bella introduzione qui:introduzione

Answer 4

Ho lavorato solo su un paio di progetti .Net (ho fatto principalmente Java) ma una cosa che consiglierei è usare uno strumento come NAnt.Ho un vero problema con l'accoppiamento della mia build all'IDE, finisce per rendere davvero complicato configurare i server di build lungo la strada poiché devi fare un'installazione VS completa su qualsiasi box da cui vuoi costruire nel futuro.

Detto questo, qualsiasi build automatizzata è migliore di nessuna build automatizzata.

Answer 5

Il nostro processo di creazione è un insieme di script Perl nostrani che si sono evoluti in un decennio circa, niente di speciale ma porta a termine il lavoro.Uno script ottiene il codice sorgente più recente, un altro lo crea, un terzo lo inserisce in un percorso di rete.Ci occupiamo dello sviluppo di applicazioni desktop, pertanto il nostro processo di gestione temporanea crea anche pacchetti di installazione da testare ed eventualmente spedire ai clienti.

Ti suggerisco di suddividerlo in singoli passaggi perché ci saranno momenti in cui vorrai ricostruire ma non ottenere l'ultima versione, o forse hai solo bisogno di riorganizzare.I nostri script possono anche gestire la creazione da diversi rami, quindi consideralo anche con qualunque soluzione sviluppi.

Infine disponiamo di una macchina di costruzione dedicata che ricostruisce il trunk e i rami di manutenzione ogni notte e invia un'e-mail con eventuali problemi o se è stato completato con successo.

Answer 6

Una cosa che suggerirei è di garantire che il tuo script di build (e il progetto di installazione, se rilevante nel tuo caso) sia nel controllo del codice sorgente.Tendo ad avere uno script molto semplice che esegue semplicemente il check-out\ottiene l'ultimo script di build "principale" e quindi lo avvia.

Lo dico perché vedo i team che eseguono semplicemente l'ultima versione dello script di build sul server ma non lo inseriscono mai nel controllo del codice sorgente o quando lo fanno lo controllano solo su base casuale.Se esegui il processo di compilazione per "ottenere" dal controllo del codice sorgente, ti costringerà a mantenere lo script di compilazione più recente e migliore.

Answer 7

Il nostro sistema di compilazione è un makefile (o due).È stato piuttosto divertente farlo funzionare poiché deve essere eseguito sia su Windows (come attività di compilazione in VS) che su Linux (come normale attività "make bla").La cosa davvero divertente è che la build ottiene l'elenco dei file effettivi da un file .csproj, crea (un altro) makefile da quello ed esegue quello.Nei processi il file make in realtà chiama se stesso.

Se questo pensiero non spaventa il lettore, allora (o è pazzo o) probabilmente può far sì che make + "il tuo manipolatore di corde preferito" funzioni per lui.

Answer 8

Usiamo UppercuT.UppercuT utilizza NAnt per costruire ed è estremamente facile da usare.

http://code.google.com/p/uppercut/

Alcune buone spiegazioni qui: UppercuT