Share
I denne opplæringsserien vil vi utforske en sjelden diskutert (men svært verdifull) prosess for å utvikle programvare som er skuffende fraværende i IOS og mobil verden: Kontinuerlig integrasjon.
I del 1 diskuterte vi begrepet kontinuerlig integrasjon og hvordan det kan hjelpe oss med å utvikle programvare raskere. Del 2 gikk gjennom å installere Apache Tomcat, webserveren som kjører vår CI-serverprogramvare. I del 3 installerte og konfigurerte vi Hudson til å overvåke prosjektet vårt og starte byggeprosessen når vi oppdaterer vårt prosjektregister. I del 4 skrev vi et grunnleggende byggeskript som samlet vårt prosjekt og genererte en IPA-fil.
Akkurat nå har vi et fungerende byggeskript, men det er så mye mer vi kan gjøre! Denne opplæringen er litt annerledes enn de andre. I stedet for å ta deg gjennom en rekke trinn, vil det være en samling nyttige tillegg som du kan legge til i skriptet ditt og, avhengig av omstendighetene dine, kan du velge å legge til dem eller ikke.
Bash-skript kan bruke funksjoner som andre språk. Store byggeskripter kan bli ganske lange, så det er viktig å organisere det så mye som mulig. Funksjoner er en fin måte å gjøre dette på.
La oss sette all vår eksisterende kode inn i en funksjon som heter "buildApp". Åpne skriptet ditt og skriv inn følgende kode:
funksjon buildApp #existing kode går her
For å ringe vår "buildApp" -funksjon, bare skriv inn følgende under funksjonsdeklarasjonen:
buildApp
Når du legger til mer funksjonalitet i skriptet ditt, kan du plassere dem i forskjellige navngitte funksjoner som "distribuereApp" eller "signApp".
En av de mest populære tjenestene som utviklere bruker til å teste sine apps, er TestFlight. TestFlight er en flott (gratis!) Onlinetjeneste som gjør at utviklere enkelt kan laste opp deres ad-hoc IPA og TestFlight tar seg av distribusjonen.
TestFlight gir en opplastings-API som vi kan ringe fra vårt bash script. Det betyr at når vi fullfører en ny bygning, kan vi umiddelbart laste den opp for å teste fly og informere våre testere om at en ny bygg er tilgjengelig.
Først må du sørge for at du har en konto og henter API-token og teamtoken. Når dette er gjort, legger du til API og lagnøkkel til toppen av skriptet ditt som variabler.
For det andre må vi forberede * .dysm filen for opplasting. Hvis du ikke husker hva * .dysm filen er for, referer tilbake til artikkel 4 for en oppfriskning. * .Dysm-filen må zippes før den kan lastes opp til TestFlight eller Apple, så det er en god ide å gjøre dette som en del av byggeprosessen.
Legg til følgende kode etter kommandoen "xcodebuild":
#zip dYSM-fil for distribusjons-cd "$ build_location / sym.root / $ configuration- $ sdk /" || dø "ikke slik katalog" rm -f "$ appname.app.dSYM.zip" zip -r "$ appname.app.dSYM.zip" "$ appname.app.dSYM"
Koden ovenfor endrer bare katalogen til plasseringen av * .dysm-filen og fjerner eventuelle zip-filer som kan ha eksistert før. Deretter oppretter det en ZIP av * .dysm-filen.
Når dette er lagt til, legg til følgende funksjon i ditt byggeskript:
funksjon deployToTestFlight / usr / bin / curl "http://testflightapp.com/api/builds.json" \ -F file = @ "$ build_location / $ appname.ipa" \ -F dsym = @ "$ build_location / sym .rot / $ konfigurasjon- $ sdk / $ appname.app.dSYM.zip "\ -F api_token =" $ TESTFLIGHT_APIKEY "\ -F team_token =" $ TESTFLIGHT_TEAM "\ -F notater =" $ appnavn lastet opp via API for testflytopplasting "\ -F notify =" False "
Nå, hvis du trenger å distribuere til TestFlight, er alt du trenger å gjøre å ringe til funksjonen "deployToTestFlight" etter at en konstruksjon er generert.
For full informasjon om TestFlights opplastings-API, sjekk ut https://testflightapp.com/api/doc/.
Noen ganger må vi kanskje endre eller lese verdier fra * .plist-filen. For eksempel vil vi kanskje lagre bygg for hver versjon av appen. Vi kan lese appversjonen fra PLIST-filen og lagre den i en passende mappe. Vi vil kanskje også redigere ikonet som brukes til en bestemt bygge, eller noen ganger til og med buntidentifikatoren.
For å sette bunt-ID-en (dvs. overskrive den opprinnelige verdien), er kommandoen:
/ usr / libexec / PlistBuddy -c "Sett: CFBundleIdentifier $ bundle_id" Info.plist
Som du kan se fra bildet ovenfor, er "CFBundleIdentifier" nøkkelen for bunt-ID-verdien, så vi "Setter" det som hva som helst $ bundle_id verdien er.
Hvis vi ønsker å lese en verdi ut av PLISTEN og sette den som en variabel i skriptet vårt, er det litt vanskeligere. Vi trenger å gjøre litt bash trickery:
app_version_number = $ (/ usr / libexec / PlistBuddy -c "Skriv ut: CFBundleVersion" Info.plist)
Ovennevnte kode i parentes utskriver bare verdien for 'CFBundleVersion' og bash scriptet fangar den verdien som en variabel og tilordner den til varianten 'app_version_number'.
I Xcode kan du bruke forskjellige konfigurasjoner for prosjektet ditt. Hver konfigurasjon kan bruke forskjellige byggeinnstillinger, kodesigneringsalternativer, til og med kompilere annerledes basert på prosessor-makroer. Selv om du oppretter nye konfigurasjoner, justerer bygginnstillingene og legger til makroer før prosessor, ligger det utenfor handlingen, jeg kan vise deg hvordan du bygger dem.
Standard konfigurasjonen når du bygger er "Release", men dette kan settes med et spesielt flagg når du ringer "xcodebuild" -kommandoen.
I dette eksemplet har vi en konfigurasjon som heter "Testing". For å bygge for denne konfigurasjonen justerer vi rett og slett vårt byggeskript basert på følgende:
konfigurasjon = "Testing" xcodebuild -target "$ appname" -konfigurasjon "$ konfigurasjon" OBJROOT = "$ build_location / $ app_version / $ konfigurasjon / obj.root" SYMROOT = "$ build_location / $ app_version / $ configuration / sym.root"
Her bygger vi vårt Xcode-prosjekt basert på en bestemt konfigurasjon og legger den i egen mappe sammen med eget versionsnummer (som vi kan få ved å se info.plisten, se tillegg 3).
Hvis du jobber for en middels til stor organisasjon, er det sjansene for at du vil bruke mer enn ett utviklings- / distribusjonsbevis for å signere appene dine. Hvis du ikke har kontroll over å skape disse sertifikatene, er det også en sjanse for at alle sertifikatene vil ha firmaets navn et sted i den.
Dette er et problem fordi nøkkelringen ikke tillater signering av et sertifikat når det er "tvetydig". Heldigvis kan vi bruke kommandoen "sikkerhet" for å legge til og slette sertifikater i løpet av vår prosess.
Først må du eksportere de relevante sertifikatene og deres private nøkler ut av nøkkelringen og legge dem til skriptkatalogen. Når du eksporterer sertifikatet og nøkkelen din, vil nøkkelringet be deg om å skrive inn en passordfrase. Skriv inn en passordfrase og lagre deretter * .p12-filen i skriptkatalogen i depotet ditt. Sett * .p12-filen som et variabelt navn i skriptet ditt.
For det andre, slett alle sertifikater på byggeserveren som kan være i konflikt med sertifikatet som skal brukes.
Til slutt legger du til følgende linje for å importere sertifikatet:
sikkerhetsimport "$ WORKSPACE / Scripts / $ CERTIFICATE_FILE.p12" -P "$ passord" -A-k ~ / Bibliotek / Nøkkelringer / login.keychain
Denne linjen importerer den angitte * .p12 inn i innlogging nøkkelringen ved hjelp av passordet "$ password".
Når du er ferdig med bygningen, fjern den fra nøkkelringen som sådan:
sikkerhetsslettsertifikat -c "$ sertifikat"
Ved hjelp av fremgangsmåten ovenfor kan du bygge appen flere ganger ved å bruke flere sertifikater som ellers ville vært tvetydige med hverandre.
Mens disse er nyttige tillegg til et hvilket som helst byggeskript, vil det alltid være spesifikke måter at du kan få det til å fungere bedre for deg. Jeg har gjort mitt beste for å lære deg det grunnleggende og gi nok av grunnlag for at du har en solid base for å eksperimentere og utvikle videre.
Et skript som inneholder alle de beskrevne trinnene ovenfor, finner du på https://gist.github.com/1404526
Jeg håper du likte denne opplæringsserien, og at du er i stand til å implementere CI og automatiserte prosesser i din utviklings arbeidsflyt. Kan du ha mange blå bygge lys! :)
Accentsconagua