În această serie de tutori vom explora un proces rar discutat (dar foarte valoros)
dezvoltând software care este dezamăgitor de absent în lumea iOS și în lumea mobilă: Integrare continuă.
Pe scurt, integrarea continuă (CI) vă permite să accelerați procesul de dezvoltare și eliberare prin verificarea constantă a depozitului de coduri pentru probleme de construcție, precum și automatizarea unei varietăți de proceduri pe care altfel ar trebui să le efectuați.
După ce ați citit acest tutorial, veți putea configura de la zero un server automat care va oferi toate beneficiile de mai sus (plus câteva altele). Mai precis, vom acoperi:
Deși vom trece în detaliu despre toate aspectele legate de configurarea CI, se presupune că nu aveți cunoștințe anterioare despre administrarea serverului, scriptingul bash sau procedurile CI. După cum sa spus, este de așteptat să aveți o înțelegere generală asupra formării Xcode și arhivării și să înțelegeți (și să aveți acces la) un server de control sursă.
Dacă nu sunteți deja în punctul în care utilizați un sistem de control al versiunilor, cum ar fi Git sau SVN pentru gestionarea codului dvs., acest tutorial va fi puțin din zona dvs. de confort. Pentru a afla mai multe despre controlul surselor și despre cum vă poate aduce beneficii, vă recomand să vă înscrieți la GitHub. Acestea oferă librării publice gratuite și au un tutorial minunat pentru utilizatorii noi cu privire la modul de configurare și utilizare a Git ca VCS.
După cum atestă cineva care a lucrat într-o echipă de dezvoltatori, gestionarea depozitelor de coduri și conflictele de cod poate fi o mare durere. Dezvoltatorii pot petrece mai multe ore după o fuziune de gestionare și curățare a conflictelor.
Pe lângă lucrul cu conflicte, construirea manuală a aplicațiilor pentru testare sau distribuirea în întreprindere poate dura o perioadă semnificativă de timp. Cineva trebuie să fie responsabil pentru păstrarea actualizării depozitului, gestionarea certificatelor pentru dezvoltatori și a profilurilor de provizionare, arhivarea codului și încărcarea fișierului IPA pe un server pentru distribuire.
Datorită complexității implicate în aceste proceduri, dezvoltatorii sunt uneori dispuși să se angajeze și să-și construiască codul și vor reuși să facă o construcție a întregului proiect doar o dată sau de două ori pe săptămână.
CI permite construirii automate după fiecare angajare în depozit. Acest lucru permite ca erorile din cod și conflictele să fie ușor identificate și rezolvate rapid și eficient. Deși acest lucru este util, de departe cea mai utilă caracteristică pe care o putem obține de la crearea unui server CI este automatizarea și distribuirea construcțiilor noastre. Imaginați-vă dacă tot ce trebuia să faceți a fost tipul svn commit -m "Fixarea bug-ului ID-ului clientului"
și 30 de secunde mai târziu construirea a fost așezată pe un site care așteaptă să fie descărcat de un tester. Configurarea unui CI poate face ca acest lucru să se întâmple!
Pentru ca CI să funcționeze eficient, dezvoltatorii trebuie să se angajeze devreme și să se angajeze des (cel puțin o dată pe zi). Serverul CI interoghează continuu magazia pentru a verifica dacă a existat o actualizare. Dacă detectează o schimbare, va începe construirea proiectului și efectuarea oricăror sarcini asociate.
Dacă construirea are succes, echipa este informată despre construirea cu succes. Dacă construirea nu are succes, echipa este informată despre:
În cazul unei construcții defectuoase, echipa poate evalua rapid modul în care a reușit construirea și rezolvarea problemei, iar problemele care trebuie rezolvate sunt mici și ușor de gestionat, deoarece ne angajăm în fiecare zi în loc de fiecare săptămână.
Testarea unităților este o lume în sine și, din păcate, nu va fi acoperită în acest tutorial. Vă încurajez să citiți despre utilizarea testelor unice ca nu numai o parte a CI, ci o parte a procesului de dezvoltare.
CI nu este cu siguranță pentru toți. Poate dura o perioadă semnificativă de timp pentru a configura un server pentru nevoile dvs. Software-ul serverului CI este cel mai bine instalat și instalat pe o mașină separată de cea utilizată pentru dezvoltare și cerințele hardware. Asta înseamnă costuri suplimentare pentru hardware.
În următorul articol vom lua mâinile murdare în configurarea serverului web Tomcat. Vom acoperi cerințele sistemului, modul de instalare și pornirea / oprirea serverului. Prindeți data viitoare!