Gennaio 2017
Volume 32 Numero 1
Il presente articolo è stato tradotto automaticamente.
DevOps per le app per dispositivi mobili - Automatizzare le distribuzioni complesse con Release Management
Da Kraig Brockschmidt | Gennaio 2017
La frase felice "Ship it," dichiara che il software si produce, ad esempio applicazioni per dispositivi mobili e i servizi back-end associati, è ora pronto per la distribuzione ai clienti o, come si è detto, "nell'ambiente di produzione." Ma come esattamente software a quel punto? Nel mio ultimo articolo di questa serie (msdn.com/magazine/mt742871), esaminato la compilazione produce gli elementi feed nella pipeline di rilascio. Bundle di elementi, denominato "rilascio", è ciò che quindi viene sottoposto a un numero qualsiasi di test e gli altri processi, come illustrato nella figura 1, per il trasferimento di produzione. La maggior parte delle attività di DevOps, infatti, comportano la distribuzione di una versione in un numero qualsiasi di ambienti in cui determinati test può essere eseguito e l'obiettivo di rilascio lungo alla fase successiva della pipeline.
Figura 1 la gestione di un rilascio si verifica tra generazione e distribuzione pubblica
Un processo di rilascio comporta potenzialmente un numero elevato di test diversi che non vengono necessariamente eseguiti contemporaneamente e che potrebbe richiedere anche diversi computer e dispositivi. Può anche coinvolgere approvazioni dirette dall'uomo che mangiano pranzo e lasciare scrivania per sera e i fine settimana. Di conseguenza, il tempo che necessario per una versione ottenere l'intera pipeline può essere facilmente pochi giorni. Nel frattempo, il team di sviluppo continua a funzionare il backlog per le versioni successive, eseguire il commit di codice per il repository di origine, quindi attivare più compilazioni che producono gli elementi che inseriscono pipeline appropriata.
Gestione del flusso di tutti questi elementi tramite più pipeline può diventare facilmente un'attività complessa e impegnativa, pertanto gli strumenti di gestione del rilascio in Visual Studio Team servizi (VSTS) e Team Foundation Server (TFS) sono una parte essenziale dello stack DevOps Microsoft.
Nell'area di gestione del rilascio aspetto principalmente supporto amministrativo e pertanto potrebbe non essere per quanto tecnicamente interessante di altre parti dello stack DevOps Microsoft. Ma, come il resto DevOps, gestione del rilascio è fondamentalmente una procedura che inizia come un elenco di passaggi che è possibile eseguire manualmente, in questo caso per convalidare che gli elementi dalla fase di compilazione o CI sono pronti per distribuire negli ambienti successive. Dopo aver chiaramente definiti questi passaggi, ovvero quando distribuire elementi a un ambiente particolare, i test da eseguire e i criteri per lo spostamento di elementi alla fase successiva, è quindi possibile utilizzare strumenti in modo incrementale automatizzare questi passaggi.
In molti modi, la gestione di una versione è molto come impostazione di una compilazione automatica, ad eccezione del fatto che l'output di release management è la distribuzione degli elementi di compilazione a posizioni in cui ottenere le persone a tali file. In definitiva, la distribuzione è come il valore contenuto nel codice sorgente viene effettivamente recapitato ai clienti, vale a dire, naturalmente, lo scopo del processo di sviluppo software.
Gli ambienti, le pipeline e la complessità di gestione
Anche se il diagramma in figura 1 Mostra solo due fasi di controllo di qualità, uno esterno e uno interno, non esiste realmente può essere qualsiasi numero di fasi. Questo avviene perché diversi tipi di test richiedono la distribuzione in ambienti in cui tali test possono essere eseguiti. Un ambiente è semplicemente una particolare configurazione dell'hardware, software e dati che sono adatti per i test desiderati o scenari di utilizzo. Ecco alcuni che sono in genere trattati nel contesto dei reparti di:
- Computer che sono in grado di eseguire unit test, test di integrazione e test dell'interfaccia utente sono in genere parte di un ambiente di test automatizzato, in genere utilizzando dati fittizi, testare i servizi e i server configurati per diversi test di carico e di stress.
- Un ambiente di test manuale configurate in modo simile è in genere esegue il proprio lavoro in cui un team di test dedicati.
- Un ambiente di gestione temporanea viene utilizzato per la distribuzione di applicazioni e servizi per i test di pre-produzione su larga scala (ad esempio l'aggiornamento test) e include la distribuzione ai clienti alfa e beta test. Questo ambiente potrebbe avvalere di dati in tempo reale e servizi in modalità sola lettura, o utilizzare le versioni di gestione temporanea per simulare completamente live attività. È anche in cui è possibile testare l'arresto anomalo del sistema e dati di telemetria sistemi di notifica e assicurarsi che genera i dati desiderati.
- Ambiente di produzione pubblica, infine, utilizza live dati pubblici e i servizi, naturalmente e viene in cui è raccogliere i dati di telemetria live che verranno infine feed in versioni successive.
È possibile, ovviamente, definire qualsiasi ambienti desiderato in base alle esigenze di convalida. In ogni caso, come creare elementi si spostano attraverso queste fasi e ambienti, e vengono applicati i test in cui, nuovamente la definisce una pipeline di rilascio e avere un numero qualsiasi di diversi instradamenti nell'operazione per scopi diversi. Con App per dispositivi mobili e i servizi back-end, sarà necessario lungo il modo più destinazioni di distribuzione, emulatori diversi o farm di dispositivo, server di prova e così via. Potrebbe inoltre essere necessario versioni scorrere solo una parte della pipeline solo per scopi di test. Con una versione pubblica, la "distribuzione" funzionalità di Google Play (bit.ly/2b7lh8j) è inoltre possibile rilasciare una nuova versione di un'applicazione a una percentuale limitata di clienti, che è essenzialmente un altro ambiente di produzione, di conseguenza, è possibile avere una pipeline di rilascio separata per tale traccia.
Che cos'è una versione?
Il termine "release management" indica chiaramente che un "rilascio" viene gestito in qualche modo. Una versione è un insieme specifico di elementi di compilazione che si desidera spostare attraverso una serie di convalide e distribuire uno o più ambienti. Tali elementi (insieme ad altre informazioni e metadati) sempre vengono trasmessi attraverso la pipeline in un'unità, indipendentemente dalle eventuali modifiche successive al repository di origine e le compilazioni che potrebbe generare, perché ogni set di elementi di compilazione sia univoco e identificati da un numero di versione completo come 1.2.8.12, dove l'ultimo numero è la compilazione. Tali versioni acquista completa end-to-end di controllo, che è la possibilità di tenere traccia di tutti gli elementi che si verifica nella pipeline di rilascio al build esatta, quindi a un set esatto di modifiche nel repository di origine.
In DevOps gergo, quindi, "avvio di una versione" significa che viene inserita un'unità che merita di elementi di compilazione in pipeline di rilascio. Figura 2 illustra il processo potrebbe aspetto: Utilizzo del backlog di progetto per la comunicazione, il team si applica una serie di controlli di convalida, indipendentemente dall'automazione, che consentono di passare alla fase successiva, fino a raggiungere produzione o rifiutare il rilascio.
Figura 2 unità di elementi di compilazione passa attraverso diverse parti interessate giungere alla produzione
Come accennato prima, è possibile infatti utilizzare un numero qualsiasi di test e ambienti e anche più ambienti di produzione di gestione temporanea (come quando si utilizza la funzionalità di implementazione di Google). Poiché un processo di rilascio può richiedere molto tempo, è possibile distribuire in produzione solo una volta alla settimana o una volta al mese. Nel frattempo, è ancora opportuno eseguire le altre versioni tramite una parte della pipeline, forse distribuzione beta tester ogni settimana per ottenere un feedback per ogni versione di produzione mensile. Probabilmente sarà anche possibile compilazioni giornaliere per andare alla gestione test ed eseguirli ogni compilazione passare attraverso una serie di test automatizzati e rapido per fornire commenti e suggerimenti in corso per il team di sviluppo. In breve, può modificare la frequenza dei rilasci, come spostarsi su e giù nel diagramma figura 2.
Pertanto, la gestione del rilascio è qualcosa che può avviare semplice e aumento delle dimensioni da lì. La forma più semplice di questa esercitazione è in effetti, qualcosa che probabilmente avete già: Creare un pacchetto dell'applicazione, distribuirla in un dispositivo (gestione temporanea) e riprodurre con l'app per verificare che funzioni come previsto. Quindi caricare il pacchetto in un archivio, fare clic su "Pubblica" e presto! Un processo di rilascio manuale per inserire l'applicazione nell'ambiente di produzione appena effettuata.
Distribuzione continua come impostazioni cultura
Come illustrato nel primo articolo di questa serie (msdn.com/magazine/mt767694), tutti i processi di DevOps iniziano con viene completamente chiarire cosa deve essere eseguita in ogni fase lungo la pipeline di rilascio, automatizzata o non. Deve essere in grado di descrivere tutti i processi in un semplice documento, in modo che ogni passaggio può essere eseguita manualmente. Quindi si è pronti per applicare l'automazione per ridurre i costi, migliorare l'affidabilità e coerenza e aumentare la frequenza di test e distribuzione.
Un obiettivo primario all'interno di DevOps è che ogni nuova versione di un'applicazione o un servizio, incluse le versioni apportando modifiche minime, flusso al più presto dal repository di origine ai clienti. Un flusso completamente automatizzato è denominato distribuzione continua (CD), che passa in stretta associazione con l'integrazione continuata (CI): Ogni commit al repository genera una nuova compilazione CI e ogni compilazione completata correttamente, che produce un nuovo bundle di elementi con un numero di versione specifico, ovvero trigger automatico un nuovo processo di rilascio. Tale processo di rilascio esegue quindi tutte le convalide necessarie prima di distribuire il pacchetto nell'ambiente di produzione. CD, significa in breve, offrire continuamente valore ai clienti il costo più basso, con intervento minimo (se presente) lungo la pipeline di rilascio.
Tenere presente, tuttavia, che sebbene CD ottimizza la pipeline di rilascio tra la fase di compilazione o elemento di configurazione e la distribuzione nell'ambiente di produzione, è comunque necessario prestare attenzione impegno da parte degli utenti per consentire il funzionamento:
- Il team necessita dei processi di revisione del codice sicuro per impedire che codice scadente il commit al repository per cominciare.
- Il team deve disporre di una confidenza elevata che test automatizzati, gli utenti che creare, intercettare la maggior parte dei difetti e impedendo loro di raggiungere i clienti.
- Poiché nessun gruppo di test è perfetto, alcuni difetti otterrà nell'ambiente di produzione, in modo che il team deve monitorare attivamente segnalazioni di arresti anomali, i dati di telemetria e suggerimenti dei clienti direttamente nell'ambiente di produzione.
- Il team deve essere eseguito rapidamente la valutazione e priorità dei problemi e alimentazione nel backlog di sviluppo in modo da ottenere rapidamente le correzioni in versioni successive.
- Problemi anche identificano i gap nel processo di revisione del codice e code coverage, pertanto determinano miglioramenti in entrambi.
In breve, CD non è una questione di automatizzare la pipeline del rilascio: CD rappresenta impostazioni cultura dell'utilizzo di commenti e suggerimenti per migliorare costantemente come valore è offerto ai clienti.
Ad esempio, la documentazione relativa a Microsoft Azure, disponibile in azure.microsoft.com/documentation, viene gestito all'interno di un repository open source su GitHub, github.com/Azure/azure-content. Esiste un sistema CI/CD completo sul posto in modo che le modifiche accettate nel repository tramite richieste pull rapidamente sfuggire nell'ambiente di produzione. Richieste pull, tuttavia, vengono analizzate attentamente dal team di contenuto Azure presso Microsoft, che impedisce le modifiche non corrette o non appropriate di entrare nel repository affatto. Accettate le modifiche, quindi passare attraverso la pipeline CI/CD automatizzata che si applica un'ampia gamma di convalida verifica (ad esempio, l'intercettazione di formattazione non corretta e collegamenti interrotti) e quindi pubblica il contenuto nel sito attivo. Il team quindi monitora i report di dati di telemetria da Application Insights insieme ai commenti dei clienti, l'utilizzo di tali informazioni per migliorare il contenuto, migliorare il test di convalida e migliorare il processo di revisione stesso.
Gestione del rilascio in VSTS
Nel mio ultimo articolo, ho esaminato impostazione compilazioni automatizzate con VSTS richiede un processo di compilazione noti, creando una definizione di compilazione da esso e che inserisce tale definizione per un agente di compilazione che è in grado di eseguire le attività necessarie per produrre un raggruppamento di elementi con un numero di versione specifico.
Gestione del rilascio in VSTS è un processo simile: Creare una definizione di rilascio che specifica come deve essere distribuito in ambienti diversi e i test e le convalide che devono essere applicati i bundle. Che definizione di rilascio viene quindi inserito in un agente della versione, una macchina opportunamente configurata, per l'elaborazione (versione agenti vengono gestiti nello stesso modo che gli agenti di compilazione, vedere bit.ly/2coBQxx). Detto questo, esistono alcune differenze significative tra generazione e rilascio definizioni:
- Una definizione di compilazione produce elementi testabili e distribuibili; una definizione di rilascio consente la distribuzione effettiva per un ambiente e l'esecuzione di test.
- Funziona sempre una definizione di compilazione da un repository di origine singolo Disegna una definizione di rilascio da un qualsiasi numero di definizioni di compilazione per raccogliere gli elementi per un rilascio.
- Spesso è possibile impostare un build completamente automatico in poche ore. una pipeline di rilascio completamente automatizzata, infatti nel corso del tempo impiegato molto più complessa per creare i test automatizzati sottostanti e scoprire i dettagli per le approvazioni, sign-OFF.
- Una tipica generazione viene completata in pochi minuti. un processo di rilascio completa, con più ambienti e i passaggi di approvazione manuale, richiederà molto più tempo. Di conseguenza, si verrà monitoraggio e il controllo delle versioni molti nella pipeline nelle diverse fasi.
- Una definizione di rilascio supporta i responsabili approvazione sia pre e post-distribuzione, con cui si inserisce il controllo manuale in delle estremità di un passaggio di rilascio, nonché le attività di intervento manuale esplicita. Un semplice esempio utilizza uno o più revisori di pre-distribuzione prima di passare all'ambiente di produzione. VSTS consente inoltre di utilizzare un gruppo di qualità di responsabile approvazione, ad esempio che solo una persona in tale gruppo è necessario per l'approvazione. In generale, si assegna un responsabile approvazione ogni volta che si desidera un essere umano coinvolti nel processo di rilascio, anche i risultati si lascia un audit trail.
Ad esempio, si supponga che dispone di un'applicazione Xamarin e codice di back-end in un repository Git in VSTS, con quattro definizioni che producono gli elementi di back-end e i pacchetti app per iOS, Android e Windows di compilazione. Un processo di rilascio semplice, visualizzando le fasi illustrate nella figura 2, potrebbe essere come segue, in cui un errore in qualsiasi punto della pipeline verrà annullata la versione:
- Eseguire unit test e integrazione di test in una compilazione corretta.
- Ambiente di test
- Distribuire l'app Xamarin Test cloud per eseguire test su dispositivi fisici.
- Distribuire il back-end in un server di test di carico locale.
- Ambiente di gestione temporanea
- Distribuire l'applicazione a beta tester utilizzando HockeyApp.
- Distribuire il back-end in un server di gestione temporanea (utilizzato da beta tester) in esecuzione nel servizio App di Azure.
- Richiedi approvazione da un approvatore che esamina feedback beta tester e valuta l'idoneità del rilascio.
- Ambiente di produzione
- Distribuire l'app in Google Play, Apple App Store e Windows Store.
- Distribuire il back-end per il servizio App di Azure di produzione.
Si noti, ancora una volta che questo processo non fornisce informazioni sull'automazione, viene semplicemente i passaggi necessari per effettuare delle versioni. Per questo motivo, è possibile avviare la creazione di definizioni dei rilasci con semplici operazioni come la distribuzione e approvatore approvazioni. Quindi, come passare diversi test raccolto, è possibile aggiungere in modo incrementale i passaggi per aumentare l'automazione. (A proposito, questo processo è essenzialmente ciò che è stato configurato per il progetto MyDriving [aka.ms/iotsampleapp], anche se termina al passaggio 3 poiché l'applicazione viene distribuita solo tramite HockeyApp.)
Tecnicamente, è possibile includere test e i passaggi di distribuzione direttamente in VSTS, una definizione di compilazione. Ciò è sufficiente quando si effettua la distribuzione e test in un unico ambiente. Quando sono coinvolti più ambienti, i responsabili approvazione e altri passaggi specifici per la versione, tuttavia, è necessario il controllo con granularità fine di Release Management.
Procedura dettagliata: Distribuzione in ambienti Azure successivi
Dopo l'operazione verrà eseguita una procedura dettagliata del processo principale dell'utilizzo di gestione del rilascio, per cui ho creato un'app Xamarin e un servizio Node. js da modelli di Visual Studio. In VSTS, creato un progetto Team denominato MSDN Magazine dicembre 2016 e aggiunto i progetti per l'archivio di origine. Impostare le definizioni di compilazione quattro per generare gli elementi appropriati che è possibile seguire una pipeline di rilascio, anche se tali elementi non qualcosa di interessante. (Per creare definizioni di compilazione per i tipi di progetto di back-end diverso, vedere "Compilare l'applicazione" [bit.ly/2cGbq7W] nella documentazione di VSTS, che assicura che si creano elementi distribuibili per Azure e illustra le attività di distribuzione in definizioni di compilazione.)
Poiché si dispone di quattro aggregazioni distinte di elementi da destinazioni diverse, alla fine ho bisogno di quattro definizioni delle versioni, ma qui inizierò con back-end. Nel portale di servizi di Team, passare al progetto Team, selezionare la scheda di rilascio e fare clic su + nuova definizione. Come con Team Foundation Build, verrà visualizzata una finestra di dialogo con (a partire dalla stesura di questo articolo) solo alcuni modelli di rilascio Azure correlati, per qualsiasi destinazione diversa da Azure, inclusi gli archivi di app, iniziare con una definizione vuota. Per il back-end, utilizza il modello di distribuzione di siti Web di Azure e fare clic su Avanti. Verrà visualizzata una finestra di dialogo di configurazione in cui seleziono la definizione di compilazione il back-end come origine degli elementi (è anche possibile utilizzare a Jenkins come origine). Inoltre selezionare una coda di agente e impostare un'opzione per la distribuzione continua, aspetto verrà trattato più avanti.
VSTS apre quindi la definizione di rilascio dell'editor visualizzato figura 3 (per impostazione predefinita saranno presenti solo un singolo ambiente). L'editor è organizzato, da sinistra a destra, in ambienti, le attività e i dettagli per l'attività. Il flusso di lavoro consiste nel creare innanzitutto un ambiente e quindi popolarlo con attività appropriate per tale ambiente. Poiché gli ambienti hanno spesso una procedura simile, è possibile creare le attività per un ambiente e quindi clonare l'ambiente per risparmiare tempo. Il + pulsante Aggiungi ambiente offre questa opzione. (È possibile creare anche meta-attività, in cui raggruppare una sequenza di attività per creare una nuova attività singola, con variabili, che possono essere utilizzate nella compilazione e rilasciare le definizioni di parametri. Per una procedura dettagliata completa, fare riferimento alla documentazione di VSTS bit.ly/2c1X3fP.)
Figura 3 modifica una definizione di rilascio in Visual Studio Team Services
Come con le definizioni di compilazione, tutte le schede che richiedono attenzione sono evidenziata in rosso, ovvero in figura 3, è necessario identificare la destinazione del servizio App di Azure per la distribuzione. Nel mio account Azure, quindi creare le istanze del servizio App denominate kraigb-MSDN1216-test, kraigb-MSDN1216-gestione temporanea e kraigb-MSDN1216-produzione. Quindi tornare a VSTS e fare clic sul collegamento Gestisci sul lato destro accanto a sottoscrizione di Azure (classico), che viene visualizzata la scheda Servizi nel Pannello di controllo progetto Team. Selezionare + nuovo Endpoint del servizio, selezionare Azure classico e ottenere una finestra di dialogo in cui immettere le informazioni di connessione. Il modo più semplice per lavorare con questo consiste nel selezionare il collegamento di file di impostazioni di pubblicazione nella finestra di dialogo passa al portale di Azure e genera un file di testo per il download, da cui è possibile copiare e incollare i valori in VSTS.
Avendo stabilito la connessione, è possibile tornare alla definizione del rilascio, aggiornare l'elenco delle sottoscrizioni e selezionare nuova connessione. Da qui per aggiornare il percorso app Web e controlli di nome app Web per selezionare l'istanza di servizio App desiderata.
Poiché la maggior parte delle informazioni di connessione per l'ambiente di Test è uguale per gli ambienti di gestione temporanea e produzione, posso clonare Test due volte e rinominare le copie. Quando esegue il clone per la produzione, tuttavia, anche impostata manualmente come un responsabile approvazione pre-distribuzione e una casella di controllo in modo da ricevere un messaggio di posta elettronica quando è in attesa che una versione. In questo modo ho inserito una pausa tra gli ambienti di gestione temporanea e produzione.
Avvio di una versione
È ora disponibile una pipeline di distribuzione di base tra tre ambienti: test, gestione temporanea e produzione, in cui le prime due distribuzioni eseguita automaticamente e il terzo è soggetta ad approvazione manuale. Per avviare manualmente una versione, I fare clic su + nella definizione di rilascio e selezionare Crea versione di rilascio. Ciò richiede la finestra di dialogo in figura 4 in cui seleziona la compilazione da utilizzare (da qualsiasi compilazione corretta che è ancora in VSTS), e in cui è possibile inoltre controllare la catena di distribuzione tra gli ambienti. Si noti che, per l'ambiente di Test, la distribuzione avviene automaticamente al momento della creazione della versione, ovvero quando si fa clic sul pulsante Crea. Gestione temporanea e produzione, analogamente, di distribuzione automatica a seconda dell'ambiente precedente, approvazioni soggette, naturalmente, per il successo di eventuali altri passaggi di rilascio in tali ambienti (ad esempio test) e qualsiasi necessarie.
Figura 4 avviare manualmente un nuovo rilascio selezionando una compilazione e impostando le distribuzioni
Una volta ho fatto clic su Crea e avvia la versione, posso effettuare ricerche in tale versione per controllarne l'avanzamento, come illustrato nella figura 5.
Figura 5 esaminare lo stato di un rilascio in corso
Che sarà condividere quando ho creato la pipeline di rilascio, utilizzando un back-end Node. js, la definizione di compilazione non crea gli elementi effettivi e pertanto la versione non è riuscita. Dopo aver selezionato questa passando per la compilazione più recente e facendo clic sulla scheda elementi nella relativa pagina di riepilogo. Una volta aggiunto l'attività Gulp necessario per produrre alcuni reale di output, come descritto nella Guida su bit.ly/2c1XhTY, tali elementi sono stati sul posto.
La pipeline versione semplice, non è non installare i test automatizzati in modo che le distribuzioni di Test e gestione temporanea è un'operazione veloce in successione e posso accedere a tali siti Web e visualizzare i risultati. Prima di qualsiasi elemento viene distribuito nell'ambiente di produzione, tuttavia, la versione indica che "un'approvazione pre-distribuzione è in sospeso per l'ambiente di"Produzione". Approvare o rifiutare,"come si può vedere nella figura 6. Posso anche ricevere un messaggio avviserà l'approvazione, con un collegamento alla pagina stessa versione in VSTS, me. Vi facendo clic sul collegamento approva o Rifiuta per indicare la decisione, aggiungere commenti, rinviare la distribuzione in un secondo momento o riassegnare l'approvazione di un altro utente. In questo caso si fa clic su Approva, la versione completa e sono in grado di visualizzare la distribuzione dell'istanza del servizio App kraigb-1216-produzione.
Figura 6 approvare o rifiutare un passaggio di approvazione manuale
Figura 6, come potete vedere, viene visualizzato lo stato per una singola versione. Facendo clic sul nome della definizione di rilascio in alto a destra, vedranno una pagina di riepilogo dello stato di tutte le versioni comunque mantenuti all'interno di VSTS. Si tratta in cui è possibile monitorare lo stato di avanzamento di ogni versione visivamente nella pipeline per la definizione e una visualizzazione simile è disponibile facendo clic su tutte le definizioni di rilascio nella struttura di spostamento sul lato sinistro del portale (non mostrato).
Distribuzione continua
Configurazione della distribuzione continua significa automaticamente l'avvio di una versione dopo una compilazione corretta utilizzando gli elementi prodotti da tale compilazione. A tale scopo, modificare la definizione di rilascio e fare clic sulla scheda trigger, in cui sono disponibili opzioni per manuale, la distribuzione continua e rilascia pianificato. Quando fa clic su distribuzione continua, quindi selezionare l'origine di tali elementi, ovvero la definizione di compilazione per il back-end, e salvare la definizione di rilascio.
A questo punto passo orizzontale fino a Visual Studio, apportare una modifica nel codice di back-end ed eseguirne il commit nel repository. Questo attiva una nuova compilazione in VSTS perché è stata selezionata la casella di integrazione continuata nella definizione di compilazione del back-end. Dopo la compilazione ha esito positivo, viene attivato automaticamente una nuova versione perché è necessario archiviare la definizione di rilascio la distribuzione continua. Pertanto, con opzioni di integrazione Continuata e CD, ho impostato la pipeline di rilascio completa tra le modifiche al codice e la distribuzione nell'ambiente di produzione, oggetto, solo l'approvazione manuale di pre-distribuzione specificati per l'ambiente di produzione nella definizione di rilascio.
Anche se questa pipeline è semplice, ora è disponibile una solida base su cui è possibile sviluppare passaggi aggiuntivi, ad esempio l'esecuzione di qualsiasi numero di test, semplicemente mediante l'aggiunta di più attività nell'ambiente appropriato nella definizione della versione e configurazione di tutte le approvazioni necessarie pre e post-distribuzione. È inoltre possibile aggiungere nuovi ambienti per dividere la pipeline in fasi distinte ancora più. Ma, indipendentemente dal numero di attività o ambienti si aggiunge, il processo di base sarà lo stesso come si è visto qui.
Procedura dettagliata: Rilasciare l'App
Con le definizioni della versione di back-end sul posto, è ora possibile creare le definizioni di tre versione per iOS, Android e Windows Compila dell'app Xamarin. Il processo è molto identico con il back-end, ad eccezione del fatto che avvia con un modello di rilascio vuota e selezionarla la definizione di compilazione specifiche della piattaforma. Nell'editor di definizione di rilascio, non sarà necessario tutte le attività per impostazione predefinita, una volta che è stato correttamente impostato gli ambienti desiderato (ad esempio Test, prima del lancio e all'avvio, per mostrare che è possibile utilizzare i nomi desiderati), fare clic su + aggiungere attività quindi selezionarne uno dalla finestra di dialogo visualizzata.
Nel caso di app per Android, le distribuzioni sono i seguenti:
- Test: Utilizzare un'attività di compilazione per compilare il codice di test, quindi utilizzare l'attività Xamarin Test Cloud per distribuire il codice di test e i file con estensione apk per eseguire tali test automaticamente nei dispositivi che ho selezionato. (Naturalmente, un account di Test Cloud è necessario utilizzare il servizio).
- Prima del lancio: Utilizzare l'attività HockeyApp il Marketplace di VSTS, innanzitutto installare pertanto viene visualizzato nella finestra di dialogo Aggiungi attività. I verrà hanno inoltre creato un account con HockeyApp e utilizzare i servizi per impostare l'elenco di clienti prima del lancio.
- Avviare: Per Android, installare l'attività di Google Play da Marketplace e selezionarlo dalla finestra di dialogo Aggiungi attività (in cui verrà visualizzata l'attività di rilascio, Alza di livello e aumentare l'implementazione separatamente). Ciò significa, naturalmente, che ho impostato manualmente gli sviluppatori con Google.
Per definizioni di rilascio my iOS e Windows, è comunque possibile utilizzare Cloud Test Xamarin e HockeyApp, ma non forniscono le piattaforme per la distribuzione automatica per i rispettivi archivi. In questi casi, l'ambiente di avvio non dispone di tutte le attività. Al contrario, un responsabile approvazione pre-distribuzione semplicemente assegnate a tale ambiente. La persona responsabile della valutazione feedback ricevuto dai tester prima del lancio e può quindi passare ai portali appropriati per caricare l'app di produzione.
Pre-Avvia distribuzione con HockeyApp
HockeyApp (hockeyapp.net) è un potente servizio DevOps per iOS, Android e Windows App prima e dopo un avvio. Fornisce HockeyApp post-avvio, arresto anomalo rapporti, feedback utente e dati di utilizzo, come verrà illustrato in un articolo successivo. Prima del lancio, HockeyApp fornisce questi servizi oltre alla possibilità di distribuire rapidamente e facilmente applicazioni di test a un numero qualsiasi di tester, indipendentemente da quali dispositivi utilizzano e indipendentemente dalla posizione in cui sono inclusi in tutto il mondo. Inoltre possibile organizzare e gestire gli addetti ai test in diversi modi, in modo è possibile controllare facilmente quale versione di ottenere i gruppi e quando.
Pre-avvio distribuzione (bit.ly/2cxruZ8) funziona tramite il client HockeyApp che i tester installare nei propri dispositivi. Quando si dispone di un nuovo test versione pronto, è caricare al portale di HockeyApp che uno manualmente o tramite una distribuzione passaggio in VSTS. Gli addetti ai test quindi riceve un messaggio che informa che la nuova versione è disponibile, e il client HockeyApp Mostra le versioni disponibili che possono essere installate utilizzando le funzionalità di caricamento laterale di varie piattaforme per dispositivi mobili.
Sviluppi futuri
In questa serie di articoli, ho ora esaminato il codice sorgente, compilazione e la gestione del rilascio, tramite il quale è possibile creare una pipeline di rilascio completa in qualsiasi numero di passaggi che è possibile richiedere e ambienti in grado di supportare qualsiasi ulteriore verifica. Tutte le connessioni di base tra il codice sorgente e i clienti è stata completata. Ora, cosa rimane, consiste nel comprendere come ascoltare ai clienti tramite il monitoraggio di applicazioni e servizi di back-end, e quindi per ulteriori informazioni sulle varie opzioni di test è possibile utilizzare, inclusi Xamarin Test Cloud.
CodePush
La distribuzione continua in genere viene utilizzata con applicazioni e servizi Web perché il processo di distribuzione è semplicemente una questione di caricamento di nuovi elementi al server appropriato. Applicazioni per dispositivi mobili, è possibile solo per le applicazioni pubblicate nell'archivio Google Play, ma non al momento per iOS e Windows poiché entrambi richiedono alcuni passaggi manuali distribuzione automatica. Inoltre, l'approvazione degli aggiornamenti di app può richiedere fino a due settimane, rende difficile sfuggire molto-meno critico, anche in semplici correzioni di bug per i clienti. Fortunatamente, applicazioni compilate tramite Apache Cordova e reagire nativo possono sfruttare il servizio Microsoft CodePush (in anteprima al momento della scrittura) al collegamento il processo. CodePush consente agli sviluppatori di distribuire automaticamente HTML, CSS, JavaScript e gli elementi statici come immagini direttamente ai dispositivi di clienti. Il servizio funziona con la query app CodePush per gli aggiornamenti che vengono quindi applicati all'applicazione in esecuzione, eliminando la necessità di passare attraverso l'applicazione di archiviare il processo di approvazione. (Questa pratica è consentita dai criteri di archivio di app, purché scopo originale dell'applicazione non cambia). Altre informazioni, vedere microsoft.github.io/code-push.
Kraig Brockschmidtfunziona come uno sviluppatore di contenuti senior per Microsoft ed è incentrato su DevOps per le applicazioni mobili. È l'autore di "Applicazioni di programmazione Windows Store con HTML, CSS e JavaScript" (due edizioni) da Microsoft Press e blog su kraigbrockschmidt.com.
Grazie al seguente esperto tecnico per la revisione dell'articolo: Alex Homer
Alex Homer è un autore tecnico di Microsoft che ha eschewed utilizzeranno i Redmond per lavorare da casa nel Derbyshire Dales notare in Inghilterra. Vari caratteri i suoi articoli sono contributi dal suo due gatti.