Share
I denne opplæringsserien vil vi utforske en sjelden diskutert (men svært verdifull) prosess av
utvikler programvare som er skuffende fraværende i IOS og mobil verden: Kontinuerlig Integrasjon.
I et nøtteskall kan kontinuerlig integrasjon (CI) øke hastigheten på utviklings- og utgivelsesprosessen ved å kontinuerlig sjekke kodelageret for byggproblemer, samt automatisere en rekke prosedyrer som du ellers ville måtte utføre selv.
Etter å ha lest denne opplæringen vil du kunne sette opp en automatisert server fra begynnelsen som gir alle fordelene ovenfor (pluss noen få flere). Spesielt vil vi dekke:
Selv om vi vil gå i detalj om alle aspekter av hvordan du konfigurerer ditt CI, antas det at du ikke har noen forkunnskaper om serveradministrasjon, bash scripting eller CI prosedyrer. Når det er sagt, er det forventet at du har en generell forståelse av Xcode og arkivering, og at du forstår (og har tilgang til) en kildekontrollserver.
Hvis du ikke allerede er på det punktet hvor du bruker et versjonskontrollsystem som Git eller SVN for å administrere koden din, vil denne opplæringen være litt ut av din komfortsone. For å lære om kildekontroll og hvordan det kan være til nytte for deg, anbefaler jeg på det sterkeste å registrere deg for GitHub. De tilbyr gratis offentlige repositorier og har en flott opplæring for nye brukere om hvordan du konfigurerer og bruker Git som VCS.
Som alle som har jobbet i et team av utviklere kan attestere, kan man administrere kodelager og kode konflikter være en stor smerte. Utviklere kan bruke flere timer etter en flettebehandling og rydding av konflikter.
I tillegg til å jobbe med konflikter, kan det være betydelig tid å bygge opp apper for testing eller bedriftsdistribuering manuelt. Noen må være ansvarlig for å holde lageret oppdatert, administrere utvikler sertifikater og provisjonsprofiler, arkivere koden og laste opp IPA-filen til en server for distribusjon.
På grunn av de kompleksitetene som er involvert i disse prosedyrene, er utviklerne noen ganger villig til å forplikte seg og bygge sin kode og klarer å lage en konstruksjon av hele prosjektet bare en eller to ganger i uken.
CI tillater at byggene skal startes automatisk etter hvert forpliktelse til depotet. Dette gjør at feil i koden og konfliktene enkelt kan identifiseres og løses raskt og effektivt. Selv om dette er nyttig, er den mest nyttige funksjonen vi kan få fra å sette opp en CI-server, automatisering og distribusjon av våre bygg. Tenk deg om alt du måtte gjøre var å skrive svn commit -m "Fast kunde ID bug" og 30 sekunder senere sitter bygningen på et nettsted som venter på å bli lastet ned av en tester. Sette opp et CI kan få det til å skje!
For at CI skal kunne fungere effektivt, må utviklere begå seg tidlig og forplikte seg ofte (minst en gang om dagen). CI-serveren overvåker kontinuerlig depotet for å sjekke om det har vært en oppdatering. Hvis det oppdager en endring, vil den begynne å bygge prosjektet og utføre eventuelle tilknyttede oppgaver.
Hvis bygningen er vellykket, blir teamet varslet om den vellykkede byggingen. Hvis bygningen ikke lykkes, blir teamet varslet om:
I tilfelle en ødelagt bygg kan teamet raskt vurdere hvordan byggingen brøt og løste problemet, og problemene som må festes, er små og enkle å håndtere fordi vi forplikter hver dag i stedet for hver uke.
Enhetstesting er en verden på seg selv og vil dessverre ikke bli dekket i denne opplæringen. Jeg oppfordrer deg til å lese opp om bruk av enhetstester som ikke bare en del av ditt CI, men en del av utviklingsprosessen.
CI er absolutt ikke for alle. Det kan ta betydelig tid å sette opp en server for dine behov. CI-serverprogramvaren er best installert og satt opp på en egen maskin til den som brukes til utvikling og maskinvarekravene. Det betyr ekstra kostnader for maskinvare.
I neste artikkel skal vi få våre hender skitne å sette opp Tomcat webserveren. Vi dekker systemkravene, hvordan du installerer det og starter / stopper serveren. Fang deg neste gang!
Accentsconagua