Che cos'è un buon processo di creazione di elementi della configurazione

https://stackoverflow.com/questions/102902

01-07-2019
|

Domanda

Cosa costituisce un buon processo di creazione di elementi della configurazione?

Usiamo CI, ma la distribuzione nella produzione è anche un obiettivo realistico di CI quando si hanno dipendenze da diversi servizi che dovrebbero essere distribuiti e anche altre app possono dipendere da questi.

Un buon processo di compilazione di elementi della configurazione è abbastanza buono quando è automatizzato per il QA e il manuale da lì?

Soluzione

Bene " dipende " :)

Usiamo il nostro sistema CI per:

build & amp; unit test
distribuisci in una casella singola, esegui test di integrazione e analisi del codice
distribuisci in ambiente di laboratorio
esegue test di accettazione in un sistema simile a un prod
drop build che passano al drop di codice per la distribuzione di prodotti

Questo è per un progetto greenfield di circa una dozzina di servizi e database distribuiti su oltre 20 server, che aveva anche dipendenze da una mezza dozzina di altri servizi "esterni".

Utilizzando uno strumento CI per distribuire il prodotto in un ambiente di produzione come obiettivo realistico? di nuovo ... " dipende "

Perché dovresti voler fare questo?

se hai la procedura puoi eseguire il rollback delle modifiche (e il rollback) più velocemente e più spesso
meno possibilità di errore umano
è possibile testare la stessa strategia di distribuzione in un ambiente di test prima di passare alla produzione e rilevare i problemi in precedenza

Alcune cose tecniche che devi affrontare prima di poter rispondere a questo:

quali sono i requisiti di uptime per il tuo sistema? Ti è consentito avere tempi di inattività o deve essere attivo 24/7?
sono in atto processi di controllo delle modifiche che richiedono l'intervento / l'approvazione umana?
la tua distribuzione è abbastanza robusta da consentire a qualsiasi componente di ripristinare uno stato noto se una distribuzione non riesce?
il tuo sistema è progettato per gestire diverse versioni di servizi o client nel caso in cui una o più distribuzioni di componenti falliscano (e hai il rollback sopra per l'ultimo bene noto)?
il processo ha le capacità per gestire una distribuzione parziale in cui un componente non può gestire versioni miste delle sue dipendenze / client?
come stai gestendo la distribuzione / gli aggiornamenti del database?
disponi di un monitoraggio in modo da sapere quando qualcosa va storto?

Ecco un paio di collegamenti correlati recenti su automazione e costruendo gli strumenti necessari .

Quando si tratta di esso, più complesso è il tuo sistema, più è difficile automatizzare tutto, ma ciò non significa che non sia un obiettivo degno, ci vuole solo molto più sforzo e forza di volontà per farlo - tutto da conoscere le difficoltà che dovrai affrontare, i problemi di cui devi tener conto (il fallimento accadrà ), le sfide politiche della costruzione di infrastrutture (rispetto a più funzionalità del prodotto).

Ora ecco il grande segreto ... le sfide tecniche sono impegnative ma non impossibili ... le sfide politiche possono essere insormontabili. Tutto ciò costa denaro, sia che si tratti di tempo di sviluppo che di acquisto di soluzioni di terzi. Quindi davvero, puoi costruire la soluzione $ 1K, $ 10K, $ 100K o $ 1M?

Qualunque sia la soluzione che scegli, assicurati che l'automazione sia robusta per prima, completa secondo ... vale a dire assicurati di avere una soluzione il più robusta possibile per ottenere l'implementazione in un ambiente di test piuttosto che una fragile soluzione che viene distribuita alla produzione.

Altri suggerimenti

CI non è inteso come meccanismo di distribuzione. è positivo che il tuo CI esegua qualsiasi distribuzione automatizzata su un server QA / Test, per garantire quegli aspetti del tuo lavoro di compilazione, ma non userei un sistema di CI come Cruise Control o Bamboo come mezzo di distribuzione.

CI è per la creazione periodica della base di codice per automatizzare l'esecuzione di test automatizzati, la verifica della base di codice tramite analisi statiche e altri controlli di tale natura.

Assicurati di comprendere l'idea alla base di una build CI. CI è l'acronimo di Continuous Integration e le build di CI sono realmente intese come build usa e getta che vengono eseguite quando uno sviluppatore controlla il codice nel sistema di controllo del codice sorgente (o ad un intervallo specificato) per garantire che le modifiche più recenti non interrompano la base di codice (da qui l'idea di integrare continuamente le modifiche alla base di codice).

A tal fine, la tecnologia utilizzata per l'attuale processo del server di compilazione è in gran parte irrilevante rispetto a ciò che accade effettivamente durante la compilazione. Come menzionato @pdavis, la build CI dovrebbe compilare la base di codice, eseguire alcune analisi del codice (FxCop, StyleCop, Lint, ecc.), Eseguire unit test e copertura del codice ed eseguire qualsiasi altra analisi personalizzata che si desidera eseguire che dovrebbe avere un impatto sul concetto di un "successo" o " fallito " costruire.

Avere una build CI distribuita automaticamente in un ambiente in realtà non rientra nel controllo di un server di build. Detto questo, puoi sempre creare un progetto separato che viene eseguito sul server di compilazione che gestisce la distribuzione quando rileva determinate condizioni (come una compilazione completata con successo), ma ciò dovrebbe sempre essere fatto come una cosa completamente indipendente.

Sto iniziando un nuovo progetto al lavoro che non vedo davvero l'ora. Siamo ancora nella fase di progettazione iniziale e abbiamo recentemente completato l'architettura del sistema logico. Abbiamo ordinato nuovi server per gli ambienti di test e di gestione temporanea e stiamo configurando un sistema di compilazione di integrazione continua (CI) basato su Cruise Control ( http://cruisecontrol.sourceforge.net/ ) e MSBuild ( http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx ) che è sostanzialmente una porta migliorata di ANT. Sembra che i file di progetto e soluzione di Visual Studio 2005 siano ora tutti in formato MSBuild. Cruise Control estraerà automaticamente la fonte da Visual Source Safe (ok, non è Subversion ma possiamo occuparci), compilandola e quindi eseguendola tramite fxCop ( http://www.gotdotnet.com/Team/FxCop/ ), nUnit ( http://www.nunit.org/ ), nCover ( http : //ncover.org/site/ ), e ultimo ma non in affitto Simian ( http://www.redhillconsulting.com.au/products/simian/ ). Cruise Control ha un'interfaccia web abbastanza buona per visualizzare tutti i risultati compilati dai vari strumenti e può persino visualizzare le modifiche al codice da una build alla successiva. Tiene inoltre traccia di tutte le build nella cronologia delle build. Non vedo l'ora dello sviluppo guidato dai test e penso che questo tipo di approccio combinato con nUnit / nCover dovrebbe darci un'idea abbastanza buona prima di lanciare cambiamenti che non abbiamo rotto nulla. Ci sono anche piani per incorporare un certo tipo di test automatizzati dell'interfaccia utente una volta che siamo abbastanza avanti nel progetto. A seconda dello strumento, questo dovrebbe essere solo una questione di installazione dello strumento sul server di generazione e di chiamarlo da Cruise Control. Dolce.

Un buon processo di CI avrà una copertura del test dell'unità completa o quasi completa. Test unitari classi e metodi di test, vs test di integrazione, che testano più parti del sistema. Quando configuri le build degli elementi della configurazione, chiedi loro di automatizzare i test delle unità. In questo modo, le build degli elementi della configurazione possono essere eseguite più volte al giorno. Abbiamo impostato la nostra esecuzione ogni 2 ore.

Puoi avere build più lunghe che vengono eseguite una volta al giorno. Questi possono utilizzare altri servizi ed eseguire test di integrazione.

Stavo guardando una presentazione ThoughtWorks (creatori di Cruise Control) e in realtà hanno affrontato questo problema. La loro risposta è che nessuna distribuzione è troppo complessa per essere testata. Perché? Perché altrimenti, i tuoi clienti diventano i tuoi tester, che è esattamente dove non vuoi essere.

Se si dispone di una struttura di distribuzione complessa, impostare un server di visualizzazione. Fingi di essere tutti i sistemi con cui devi parlare. Possono sempre avviarsi in un buono stato noto, perché è possibile ripristinare un'immagine pulita.

Per rispondere alla tua domanda iniziale, un buon processo è quello che consente la comunicazione tra il repository e gli sviluppatori. Se il repository si trova in uno stato non valido (codice non di compilazione, test non riusciti, ecc.), Gli sviluppatori lo conoscono al più presto, in modo che possano correggerlo.

Più tardi viene scoperto un bug, più costoso è riparare. Quindi i bug dovrebbero essere scoperti il ??prima possibile. Questa è la motivazione dietro CI.

Un buon CI dovrebbe garantire la cattura del maggior numero possibile di bug. L'intera applicazione comprende codice (spesso in più lingue), schema del database, file di distribuzione, ecc. Gli errori in uno di questi possono causare bug - quindi l'IC dovrebbe cercare di esercitarne il maggior numero possibile.

CI non sostituisce una corretta disciplina del QA. Inoltre, la CI non deve essere molto completa il primo giorno del progetto. Si può iniziare con un semplice processo CI che esegue compilation di base & amp; test unitario inizialmente. Quando scopri più classi di bug nel QA, dovresti adattare il processo CI per cercare di individuare le occorrenze future di tali bug. Può anche includere controlli statici di analisi del codice, in modo da poter implementare ideali di progettazione e codifica coerenti in tutta la base di codice.

Un buon processo di compilazione di elementi della configurazione è abbastanza buono quando è automatizzato per il QA e il manuale da lì?

Penso che quel "manuale" la distribuzione viene utilizzata quando una persona con ruolo di ingegnere della distribuzione teme che qualcosa dopo la distribuzione possa andare storto. Non ha fiducia nell'affidabilità e stabilità degli strumenti di distribuzione.

Questa impresa può andare via con i test del processo di distribuzione automatizzata in un ambiente simile a un prod. Inoltre deve testare un meccanismo di rollback dopo la distribuzione.

Quando queste funzioni vengono testate abbastanza, acquisirai fiducia in questo processo e nello strumento che usi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow