Sådan automatiseres CI til ethvert iOS-projekt

Enhver hvorfor hvert projekt skal have det

Travis CI Build Log

Hvad er kontinuerlig integration (CI)?

Kontinuerlig integration (CI) er processen med at flette al ny kode tilbage til hovedgrenen. Målet er at opretholde en bygbar hovedgren og begrænse bugs ved hjælp af enhedstest.

Det lyder som en god idé, ikke? Hvad hvis jeg fortalte dig, at vi kan vide, hvornår vores kode vil ødelægge noget, før vi rent faktisk fletter noget?

Automatiske CI Build Services

Tjenester såsom Travis CI, Circle CI og Bitrise kan automatisere CI-processen. De tillader tilpassede builds, der kan køre hver gang du opretter en ny Pull Request.

CI build-tjenester bruger en dedikeret virtuel maskine til at opbygge et projekt. Ved at oprette et nyt eksempel på en computer kan buildtjenesten begrænse ukendte variabler. Noget så simpelt som hvilken version af Xcode et system bruger, kan påvirke resultatet af build.

Til dette indlæg valgte vi Travis CI som vores valg af CI build-service. De tillader gratis CI-build til open source-projekter og integreres godt med Github.

Krav

En GitHub-konto er nødvendig for at synkronisere med Travis CI. Når de er aktiveret, er offentlige lagre fra Github i stand til at synkronisere med Travis CI. Eksempelopbevaringsstedet, der bruges i dette indlæg, er tilgængeligt her. Inkluderet er et Xcode-arbejdsområde, konfigureret med CocoaPods og et enhedsforsøgsmål.

YAML-filen

CI build-tjenester kan opsætte og opbygge ethvert projekt ved hjælp af en brugerdefineret .yml-fil. Da vi bruger Travis CI, bliver vi nødt til at oprette en .travis.yml-fil i roden af ​​vores projekt.

Nedenfor vises en prøve .travis.yml-fil, som vi vil bruge til at analysere de tilpassede egenskaber.

1. sprog

Travis CI understøtter en lang række sprog, herunder Swift og Objectivity-C. At indstille sprog til objektiv-c fungerer for begge sider.

2. osx_image

Xcode-versionen der skal bygges fra. På dette tidspunkt bruger vi den seneste version, Xcode 10.1.

3. xcode_workspace

Stien til Xcode-arbejdsområdefilen. For de fleste projekter er placeringen af ​​Xcode-arbejdsområdefilen rodmappen. Hvis du vil indstille stien som rodmappen, skal du indstille attributten xcode_workspace til navnet på arbejdsområdefilen.

Hvis projektet findes i en undermappe, skal du ændre det aktuelle bibliotek, som build kører på. Ring til cd-kommandoen i afsnittet before_install for at indstille arbejdsmappen. Nedenfor vises et eksempel på et projekt, der har en sti: ./Example/TravisCIBlog.xcworkspace

4. xcode_scheme

Navnet på det ønskede Xcode-skema, som CI-bygningen skal køre på. Placeringen af ​​det valgte skema er nær simulatorvælgeren på Xcode.

5. xcode_destination

Xcode-destinationen indeholder oplysninger om simulatorindstillingerne. Platformen skal indstilles til iOS Simulator, og operativsystemet skal indstilles til den ønskede iOS-version af simulatoren. Navnet skal også indstilles til navnet på den iPhone-simulator, som buildene løber fra.

Vær opmærksom på, at en iOS-simulator IKKE kan køre alle de tilgængelige iOS-versioner. For eksempel har en iPhone XR ikke support til at køre på nogen version af iOS 11. Den begrænsende faktor er, at en iOS-simulator ikke kan køre en iOS-version, der går forud for lanceringen af ​​enheden. IPhone XR frigivet med iOS 12.0, hvorfor den ikke kan køre iOS 11, da den aldrig blev frigivet med iOS 11. Den understøttede Travis CI-simulatorliste er tilgængelig her.

Et andet problem, man skal kigge efter, er en uoverensstemmelse i projektets implementeringsmål og den ønskede OS-version.

Implementeringsmål for Xcode-projekt

Xcode-installationsmålet kan IKKE være lavere end OS-versionen, der findes i .yml-filen. Hvis implementeringsmålet er lavere, vil build ikke kunne køre på den ønskede simulator. OS-versionen skal mindst være implementeringsmålet eller højere for at builden skal lykkes.

6. før_installation

Her finder sted enhver ekstra opsætning, før CI starter installationsprocessen. Da vi har et projekt med en Podfile, har vi tilføjet podinstallation til trinet før_installation.

Udløser en bygning

Når du har konfigureret .travis.yml-filen, skal du skubbe ændringerne til repos oprindelse. For at udløse en build skal du navigere til projektet og vælge menuen "Flere indstillinger" og derefter "Trigger Build". Det tager et par minutter at gennemføre hele processen, og hvis der ikke er nogen fejl, vil det se ud som billedet herunder.

Vellykket CI Build

Føj en Build Status-badge til din README

En build-status-badge er en fantastisk måde at vise den aktuelle status for dit projekt fra README. Du har måske bemærket, at nogle populære open source-pods har dette på deres README.

For at tilføje en skal du gå til dit projekt på Travis CI og vælge badge "build passing" ud for projektets navn. Der vil være en mulighed for hvilken gren badget skal repræsentere og typen af ​​badge. For typen skal du vælge Markdown for at være i stand til at tilføje den til README. Den genererede tekst behøver ikke ændringer for at føje den til README.

Hvis noget går galt, kan badget også klikkes for at hjælpe med at ruteudviklere til Travis CI-build-siden.

Hvad er næste ...

Nu hvor vi har tilføjet en CI build-service til projektet, kan vi opbygge nye funktioner med tillid. Når du opretter nye Pull Requests, opretter Github automatisk en ny build på Travis CI. Status for bygningen vises i Pull Request som vist på billedet herunder.

Mere information om, hvordan du opsætter og tilpasser din .travis.yml-fil, kan findes her:

Tak for at have læst!

Hvis du har spørgsmål, kommentarer eller anmodninger om fremtidige artikler, bedes du efterlade en kommentar nedenfor!