In che modo la tua azienda distribuisce il suo software?

Question

Sono attualmente impegnato in un breve progetto di ricerca. La società in cui lavoro ha un processo di rilascio molto pesante che sta peggiorando col passare del tempo. Stiamo riscontrando un numero sempre maggiore di problemi con ogni versione, che sta iniziando a influire seriamente sui nostri programmi di consegna e sulla qualità di ogni versione. Forniamo un grande prodotto SAAS distribuito su Internet in una web farm di grandi dimensioni. Il nostro processo di implementazione è attualmente gestito da un team dedicato, con un coinvolgimento minimo degli sviluppatori. Siamo principalmente un negozio .NET, tuttavia abbiamo anche un paio di componenti Java.

Sto studiando come migliorare il nostro QA e il processo di implementazione per ridurre gli sprechi e portare più processi sotto il controllo dei nostri team di sviluppo. Sono interessato a sapere come la tua azienda distribuisce i tuoi prodotti (preferibilmente SAAS, ma non limitati a tali prodotti) alla produzione, così come il viaggio attraverso i test durante il suo percorso. Sono curioso di sapere cosa ha funzionato e cosa no, e sono sicuro che molti di voi hanno storie da raccontare.

EDIT (RFC aggiuntive):

Come ho continuato la mia ricerca, mi sono imbattuto nel concetto di "Deployment continuo", a quanto pare sperimentato dal Team 3D comunità online IMVU. Sembra un concetto intrigante, forse un po 'complesso. Sono curioso di sapere se qualcuno qui su SO ha qualche esperienza con la distribuzione continua? In particolare con un progetto ampio e complesso che ha molte parti. Non è necessario necessariamente implementare continuamente la produzione ... per le nostre esigenze a breve termine, consideriamo solo l'implementazione continua in ambienti interni di dev/qa/perftest. Se qualcuno ha implementato la distribuzione continua, sono anche curioso di sapere come hai gestito lo schema del database e le modifiche/rollback dei dati.

Grazie!

Answer 1

Distribuiamo una soluzione SaaS di servizi finanziari nell'ambiente cloud Amazon AWS. La nostra soluzione è al 100% Java, quindi molti degli strumenti non sono applicabili ma i concetti dovrebbero.

Prima di tutto, riduciamo il numero di sorprese quando arriva il momento di fare un rilascio eseguendo un processo di integrazione continua. Ogni volta che il codice sorgente viene controllato da uno sviluppatore, l'intera soluzione viene creata automaticamente e tutti i test unitari vengono eseguiti automaticamente. Le notifiche di errore vengono inviate via e-mail allo sviluppatore in questione e al lead del team.

AWS è costruito attorno al concetto di macchine virtuali. Ne approfittiamo creando un'immagine di una macchina virtuale (Amazon li chiama AMI) che contengono la versione specifica del sistema operativo e delle applicazioni (Java, DB, ecc.) Che desideriamo. Il processo di generazione crea tutte le risorse utente distribuibili e quindi le copia in un'istanza in esecuzione basata su quell'AMI. È lo stesso identico processo per tutti gli ambienti (TEST, DEMO, PROD), ad eccezione di un singolo progetto di configurazione che incapsula le differenze di versione (ad esempio stringhe di connessione).

QA verifica il risultato nell'ambiente TEST. Una volta approvata la versione, ripetiamo il processo di generazione con targeting PROD (utilizzando le stesse revisioni di controllo della versione.) Ricorda che l'unica differenza tra ogni ambiente è un progetto di configurazione).

A quel punto creiamo una macchina virtuale (istanza) in esecuzione sull'AMI di base con la base di codici PROD e la chiamiamo STAGING. STAGING passa attraverso una serie di test di accettazione, sia automatici che manuali. Ecco la parte davvero bella ... ora, bruciamo questo ambiente (base AMI più nuova versione della nostra applicazione) in un nuovo AMI (immagine della macchina virtuale). Quindi creiamo nuove istanze in esecuzione dei nostri server delle app basate su questa nuova immagine, aggiorniamo il bilanciamento del carico in modo che punti a queste nuove istanze e uccida solo le vecchie istanze. Questa è la bellezza dell'uso di macchine virtuali (almeno, questa è una delle bellezze).

Ogni volta che è necessario regolare la capacità (ore/giorni di picco), vengono create nuove istanze del server delle applicazioni dalla stessa AMI di produzione e registrate con il servizio di bilanciamento del carico. Al termine del picco, li rimuoviamo dalla rotazione del bilanciamento del carico, quindi eliminiamo le istanze aggiuntive dopo alcuni minuti (per consentire il completamento delle sessioni esistenti).

Answer 2

Non stai dicendo che cosa sta causando i problemi con le tue uscite? Stavamo avendo problemi perché i file errati finivano nella nostra build. La nostra risposta a questo è stato costruire uno strumento che ci desse controllo e visibilità su tutti i file nella nostra build. Here è un webcast dello strumento che abbiamo creato.

Answer 3

Disclaimer: Posso vendere quello che ho scritto, ma per ora è gratuito (e non è stato rilasciato ufficialmente).

Utilizziamo un sistema che ho scritto.

Funziona integrando con il controllo sorgente e il server CI. Mi consente di inviare il codice a SVN, attendere una build sul build server, quindi, tramite l'interfaccia apps, configurarlo per una build specifica, confermarlo indietro nel controllo del codice sorgente e quindi, sui server, aggiornerà. La cosa bella è che puoi aggiornare asynch, così tutti i server avranno la nuova build intorno allo stesso tempo.

È un po 'più complicato di così, e richiede un certo modo di essere impostato, ma è davvero molto bello (secondo la mia opinione molto parziale) quando è in azione. Mandami una mail se vuoi una versione 'alpha' gratuita con cui giocare. Qualsiasi beta di esso sarà gratuito pure.

- Edit:

processo generale:

1. impegnarsi a tronco
2. Attendere la costruzione dal server CI, build è 'nudo' (non configurato per qualsiasi server)
3. Deploy compilare, utilizzando lo strumento ("dashy"), per testare il server
4. Test
5. Siate soddisfatti dei test
6. Deploy build (stessa corporatura) a vivere server

Le fasi "Distribuzione" si compone di impegnarsi in SVN, e quindi il programma, installato anche sul vostro server web, ottiene la build da SVN.

Effettivamente, aggiungo un nuovo oggetto di livello "base" nella struttura SVN standard. Normalmente hanno:

/trunk 
/braches 
/tags 

Con dashy, aggiungo /releases

/trunk 
/braches 
/tags 
/releases 

Answer 4

Abbiamo una soluzione SaaS e fondamentalmente utilizzare lo stesso processo (server di integrazione continua, script di distribuzione per il test-staging-produzione) come Eric sopra, ma lo distribuiamo alla nostra infrastruttura utilizzando script personalizzati basati su PSTools (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx) per eseguire tutte le operazioni di copia sui nodi della farm.

Per ogni distribuzione valutiamo se è possibile consentire a nodi diversi di avere versioni diverse dell'app (es.nessun rischio di integrità dei dati) o dobbiamo disattivare l'app offline per alcuni secondi per sincronizzare tutti i nodi (in genere occorrono circa 20 secondi affinché l'app ritorni online, dal momento che copia le app da un nodo principale) ; ma l'intera chiave è avere una configurazione del processo di distribuzione "one key".