Share
In questa serie di tutorial esploreremo un processo raramente discusso (ma molto prezioso) di
sviluppo di software che è deludentemente assente nel mondo iOS e mobile: integrazione continua.
In breve, Continuous Integration (CI) consente di accelerare il processo di sviluppo e rilascio controllando costantemente il repository del codice per i problemi di build e automatizzando una serie di procedure che altrimenti dovresti eseguire tu stesso.
Dopo aver letto questo tutorial sarai in grado di configurare da zero un server automatico che fornirà tutti i vantaggi di cui sopra (più alcuni altri). Nello specifico, tratteremo:
Sebbene andremo nei dettagli su tutti gli aspetti di come configurare l'elemento della configurazione, si presume che non si abbia una conoscenza preliminare dell'amministrazione del server, degli script di bash o delle procedure CI. Detto questo, ci si aspetta che tu abbia una conoscenza generale di Xcode e delle build di archiviazione e che tu capisca (e abbia accesso a) un server di controllo del codice sorgente.
Se non sei già al punto in cui utilizzi un sistema di controllo della versione come Git o SVN per la gestione del codice, questo tutorial sarà un po 'fuori dalla tua zona di comfort. Per ulteriori informazioni sul controllo del codice sorgente e su come può avvantaggiarti, ti consiglio vivamente di iscriverti a GitHub. Offrono repository pubblici gratuiti e hanno un ottimo tutorial per i nuovi utenti su come impostare e utilizzare Git come VCS.
Come può testimoniare chiunque abbia lavorato in un team di sviluppatori, gestire archivi di codici e conflitti di codice può essere un enorme problema. Gli sviluppatori possono trascorrere diverse ore dopo la fusione e la gestione dei conflitti.
Oltre a lavorare con i conflitti, la creazione manuale di app per il testing o la distribuzione aziendale può richiedere molto tempo. Qualcuno deve essere responsabile della conservazione del repository, della gestione dei certificati dello sviluppatore e dei profili di provisioning, dell'archiviazione del codice e del caricamento del file IPA su un server per la distribuzione.
A causa delle complessità coinvolte in queste procedure, gli sviluppatori a volte detestano il commit e costruiscono il loro codice e riusciranno a creare una build del progetto completo solo una o due volte alla settimana.
CI consente di avviare automaticamente le build dopo ogni commit nel repository. Ciò consente di identificare e risolvere in modo rapido ed efficace gli errori nel codice e nei conflitti. Sebbene ciò sia utile, la funzione di gran lunga più utile che è possibile ottenere dalla configurazione di un server CI è l'automazione e la distribuzione delle nostre build. Immagina se tutto quello che dovevi fare fosse digitare svn commit -m "Risolto il bug dell'ID cliente" e 30 secondi dopo la build era seduta su un sito Web in attesa di essere scaricata da un tester. Configurare un CI può farlo accadere!
Affinché la CI funzioni efficacemente, gli sviluppatori devono impegnarsi presto e impegnarsi spesso (almeno una volta al giorno). Il server CI esegue continuamente il polling del repository per verificare se è presente un aggiornamento. Se rileva una modifica, inizierà a costruire il progetto e ad eseguire le attività associate.
Se la costruzione ha esito positivo, al team viene inviata una notifica della build andata a buon fine. Se la compilazione non ha esito positivo, al team viene inviata una notifica di:
Nel caso di una build rotta, il team può valutare rapidamente come si è rotta la build e risolvere il problema ei problemi che necessitano di essere risolti sono piccoli e facili da gestire perché ci stiamo impegnando ogni giorno invece che ogni settimana.
Il test delle unità è un mondo su se stesso e sfortunatamente non sarà trattato in questo tutorial. Vi incoraggio a leggere sull'uso dei test unitari non solo come parte del vostro CI, ma come parte del vostro processo di sviluppo.
CI non è certamente per tutti. Può essere necessario molto tempo per configurare un server in base alle proprie esigenze. Il software server CI viene installato e configurato al meglio su una macchina separata rispetto a quella utilizzata per lo sviluppo e i requisiti hardware. Ciò significa costi aggiuntivi per l'hardware.
Nel prossimo articolo ci sporcheremo le mani configurando il server web Tomcat. Tratteremo i requisiti di sistema, come installarlo e avviare / arrestare il server. Prenderti la prossima volta!
Accentsconagua