Continue integratie serie-introductie

In deze tutorialserie zullen we een zelden besproken (maar zeer waardevol) proces van onderzoeken
software ontwikkelen die teleurstellend afwezig is in de iOS- en mobiele wereld: continue integratie.

In een notendop stelt Continuous Integration (CI) u in staat om het ontwikkelings- en releaseproces te versnellen door de code-repository voortdurend te controleren op build-problemen en een verscheidenheid aan procedures te automatiseren die u anders zelf zou moeten uitvoeren.

Na het lezen van deze tutorial zul je in staat zijn om een geautomatiseerde server op te zetten die alle bovengenoemde voordelen zal bieden (plus een paar meer). Concreet gaan we het hebben over:

De theorie achter continue integratie.
Installatie van de Tomcat Apache Webserver. Dit wordt gebruikt om de CI-software uit te voeren.
Hudson installeren. Dit is de CI-software die de repository controleert en de
bouwen.
Het bash-build-script schrijven. We zullen de basisprincipes van Bash bespreken en ons Xcode-project compileren vanaf de opdrachtregel.
Uitbreiding van het build-script op verschillende manieren, inclusief geautomatiseerde implementatie.

Vereiste kennis

Hoewel we uitgebreid ingaan op alle aspecten van het instellen van uw CI, wordt ervan uitgegaan dat u geen voorkennis hebt van serverbeheer, bash-scripting of CI-procedures. Dit gezegd hebbende, wordt er verwacht dat je een algemeen begrip hebt van Xcode en het archiveren van builds, en ook dat je een broncontroleserver begrijpt (en er toegang toe hebt)..

Als u zich nog niet op het punt bevindt waarop u een versiebeheersysteem zoals Git of SVN gebruikt voor het beheer van uw code, zal deze tutorial een beetje buiten uw comfortzone zijn. Om te leren over bronbeheer en hoe dit ten goede kan komen aan u, raad ik u ten zeerste aan om u aan te melden voor GitHub. Ze bieden gratis openbare repositories en hebben een geweldige handleiding voor nieuwe gebruikers over hoe Git als een VCS kan worden ingesteld en gebruikt..

Ook verkrijgbaar in deze serie:

Continue integratie: serie-introductie
Continue integratie: Tomcat-installatie
Continue integratie: Hudson-installatie
Continuous Integration: Scripting Xcode Builds
Continuous Integration: Script Enhancements

Wat is continue integratie?

Zoals iedereen die in een team van ontwikkelaars heeft gewerkt, kan bevestigen, kan het beheren van coderepository's en codeconflicten enorm lastig zijn. Ontwikkelaars kunnen enkele uren na een samenvoeging doorbrengen met het beheren en opschonen van conflicten.

Naast het werken met conflicten kan het handmatig verwerken van apps voor testen of bedrijfsdistributie een aanzienlijke hoeveelheid tijd kosten. Iemand moet verantwoordelijk zijn voor het up-to-date houden van zijn repository, het beheren van de ontwikkelaarcertificaten en provisioningprofielen, het archiveren van de code en het uploaden van het IPA-bestand naar een server voor distributie.

Vanwege de complexiteit van deze procedures, hebben ontwikkelaars soms een hekel aan het plegen en bouwen van hun code en kunnen ze het volledige project slechts een of twee keer per week bouwen.

Met CI kunnen de builds na elke commit automatisch worden gestart naar de repository. Hierdoor kunnen fouten in de code en conflicten eenvoudig en snel worden geïdentificeerd en opgelost. Hoewel dit handig is, is verreweg de meest bruikbare functie die we kunnen verkrijgen bij het opzetten van een CI-server, het automatiseren en distribueren van onze builds. Stel je voor dat je alleen maar hoeft te typen svn commit -m "Probleem met klant-ID opgelost" en 30 seconden later zat de build op een website te wachten om te worden gedownload door een tester. Het opzetten van een CI kan dat mogelijk maken!

Hoe het werkt

Om te zorgen dat CI effectief werkt, moeten ontwikkelaars zich vroeg engageren en vaak committeren (minstens één keer per dag). De CI-server peilt voortdurend naar de repository om te controleren of er een update is geweest. Als een wijziging wordt gedetecteerd, wordt het project gestart en worden bijbehorende taken uitgevoerd.

Als de build succesvol is, wordt het team op de hoogte gebracht van de succesvolle build. Als de build niet succesvol is, wordt het team op de hoogte gebracht van:

Wie in het team heeft de build gebroken
Door welke veranderingen is de build kapot gegaan

In het geval van een kapotte build, kan het team snel beoordelen hoe de build brak en ging het oplossen van het probleem, en de problemen die moeten worden opgelost zijn klein en gemakkelijk te beheren omdat we elke dag in plaats van elke week committeren.

De belangrijkste voordelen van continue integratie

Problemen met de build worden vroeg geïdentificeerd.
Geïdentificeerde problemen zijn meestal kleine problemen die gemakkelijk op te lossen zijn.
Geautomatiseerd bouwen, ondertekenen en distribueren van de app bespaart tijd.
Constante toegang tot de 'nieuwste' build voor testers.
Unittests kunnen op elke build worden uitgevoerd, waardoor ontwikkelaars functionele problemen en compilatiefouten kunnen detecteren.

Unit-testen is een wereld op zichzelf en wordt helaas niet behandeld in deze tutorial. Ik raad u aan om meer te lezen over het gebruik van unit-tests als niet alleen onderdeel van uw CI, maar ook als onderdeel van uw ontwikkelingsproces.

De belangrijkste nadelen van continue integratie

CI is zeker niet voor iedereen. Het kan een aanzienlijke hoeveelheid tijd kosten om een server in te stellen voor uw behoeften. De CI-serversoftware kan het beste worden geïnstalleerd en ingesteld op een afzonderlijke machine die wordt gebruikt voor de ontwikkeling en de hardwarevereisten. Dat betekent extra kosten voor hardware.

De volgende keer

In het volgende artikel gaan we onze handen vies maken bij het opzetten van de Tomcat-webserver. We bespreken de systeemvereisten, hoe u deze installeert en hoe u de server start / stopt. Vang je de volgende keer!

Code