Il test di Joel include la domanda:
Can you make a build in one step?
Che è importante, ma mi chiedo, quanto sono stati snelli alcuni dei processi di distribuzione ?
Si applica tutto il software da un involucro a involucro fino al Web: qual è il miglior ambiente di distribuzione con cui hai lavorato e quali passaggi sono stati coinvolti?
È l'ambiente che ho creato nella mia azienda e sto lavorando proprio ora.
Siamo un team di 4 sviluppatori , che lavorano su un progetto desktop Java . Il codice sorgente è in Mercurial , con il repository principale ospitato sul nostro server di sviluppo. Utilizziamo principalmente TortoiseHg per lavorare con Mercurial. I progetti che apriamo sono in BitBucket . Il progetto è stato creato con Maven . L'IDE che utilizziamo è Netbeans , che funziona molto bene con Maven (funziona anche con Mercurial).
Il nostro server di sviluppo esegue Archiva , che è un repository Maven proxy. Usiamo maven per costruire il progetto, ma lo usiamo anche per eseguirlo (mvn exec), per distribuire le risorse generate su Archiva (versione mvn) e per generare un assembly dalle risorse ospitate da Archiva (mvn assembly).
Abbiamo anche un bugtracker Redmine ed è a conoscenza dei repository Mercurial. Utilizziamo un client RSS per essere informati sull'attività del progetto (da Redmine e Mercurial). Abbiamo anche un server Jabber per inviare messaggi e file tra loro.
Abbiamo configurato un server Hudson (integrazione continua) e un server Sonar (metriche del codice). Ma in pratica non lo usiamo veramente.
Abbiamo la possibilità di utilizzare Windows o Linux
Esempio per rilasciare una versione 1.1.3
# tags the VCS, updates all the version numbers in the maven config file
mvn --batch-mode release:prepare -DreleaseVersion=1.1.3 -DdevelopmentVersion=1.1.4-SNAPSHOT
# performs a clean build, runs all tests, deploys to the server
mvn release:perform
# creates a unique jar (the final product) from the previously deployed artifacts (no recomilation involved)
<update the version number in a config file to 1.1.3>
mvn assembly:assembly
Ho usato fabric per configurare la distribuzione nel mio nuovo avvio.
L'aggiornamento del server live è semplice come:
fab prod upgrade
Questo ottiene tutta la sorgente più recente, crea una pagina di manutenzione, migra il database, imposta il nuovo codice, ottiene tutte le dipendenze, ferma / avvia tutto, ecc. Tutte le informazioni pertinenti (password, nomi utente, ecc. .) sono tutti richiesti in anticipo.
Eseguo semplicemente il comando, inserisco alcune informazioni e vado a prendere una tazza di caffè. Tutto è in ordine quando torno.
Non sono sicuro di essere d'accordo con Joel su questo - sicuramente nessun passo è meglio di uno?
Usiamo Hudson per creare script delle nostre build (continuamente su Mac e Windows), inclusa la creazione di programmi di installazione e immagini CD per le poche volte in cui inviamo effettivamente una vera casella. Testiamo sempre dall'installatore in QA.
Usiamo anche Hudson per copiare gli installatori nell'area "beta" del nostro sito web dal vivo una volta al giorno.
Quindi, in sostanza, possiamo distribuire agli utenti ogni giorno senza alcun passaggio. Quando rilasciamo una versione ufficiale, cambiamo semplicemente i nomi dei file degli installer in CMS per fare in modo che gli attuali beta installatori siano quelli di rilascio e cambiamo lo script di build Ant per passare al nuovo numero di versione (che diventa la nuova beta).
Avere impostato e funzionante rende il giorno di rilascio un non-evento completo (che è esattamente quello che dovrebbe essere). Non abbiamo avuto un errore nel giorno del rilascio per un po 'di tempo (era un evento normale)!
In uno dei miei clienti, lavoriamo su Rails e abbiamo tutto configurato in modo che la distribuzione passi da git. Noi non "costruiamo", però, dato che è Rails.
Quindi il processo di distribuzione è qualcosa di simile a
git checkout review
git merge whatever-that-was
git push
cap review deploy:migrations
Il mix tra Capistrano e GIT funziona abbastanza bene.
Naturalmente, ulteriori script dovrebbero essere in grado di saltare alcuni di questi passaggi.
Il mio flusso di lavoro corrente è così.
Questo può essere programmato in un unico passaggio.
Abbiamo un'applicazione Java Web Start - stiamo per ricostruire la procedura di distribuzione come file WAR con il file JNLP adattato all'URL richiesto quando richiesto dagli utenti.
Mi aspetto che vada estremamente liscio.
Ultimamente abbiamo usato molto git. L'idea di registrare le distribuzioni nei repository git così puoi semplicemente chiedere a git di verificare la versione che vuoi eseguire. Aggiornamenti in background, tempo di checkout molto breve per aggiornare i file effettivi, tempo di checkout molto breve per tornare a una versione precedente in caso di problemi. Penso che potrebbe funzionare molto bene per noi.
È scontato che ora è piuttosto datato, ma in passato avevo i seguenti passaggi per distribuire il mio codice molte lune fa che ho trovato il migliore che avessi:
Questo avveniva alla fine degli anni '90 quando stavo programmando in Visual C ++ su NT 4.0 per un dot-com. La maggior parte dei processi di implementazione sono diventati più complicati nell'avere task nAnt e altre cose extra come occuparsi di server di produzione con bilanciamento del carico, mentre nel resto della giornata avevamo solo una scatola di produzione.
Il corso che passa il processo a un tecnico di rilascio è migliore, ma non è esattamente lo stesso di quando inserisco il codice in the wild.
Non per niente, ma facendo clic con il pulsante destro del mouse su un'app web ASP.NET e selezionando Pubblica è stata una piacevole sorpresa quando ho dovuto distribuire un'applicazione. Certo, ho dovuto impostare la directory virtuale e simili su IIS in anticipo, ma l'implementazione di nuove versioni è a portata di clic.
Leggi altre domande sui tag project-management deployment