We publiceren iOS-apps in de App Store met GitLab en fastlane

Hoe GitLab met fastlane applicaties voor iOS bouwt, ondertekent en publiceert in de App Store.

Onlangs hadden we een post over hoe je snel een Android-app kunt bouwen en starten met GitLab en fastlane.Hier zullen we zien hoe we een iOS-app kunnen bouwen en lanceren en deze kunnen publiceren in TestFlight. Kijk eens hoe geweldig het is ik breng een wijziging aan op de iPad Pro met de GitLab Web IDE,ik neem de build en ontvang de update van de testversie van de app op dezelfde iPad Pro waarop ik deze heb ontwikkeld.

Hier nemen we een eenvoudige iOS-app op Swift,waarmee ik een video heb opgenomen.

Een paar woorden over de configuratie van de Apple Store

We hebben een app in de App Store, distributiecertificaten en een initiële profiel nodig om alles met elkaar te verbinden.

Het moeilijkste hier is het instellen van signatuurrechten in de App Store. Ik hoop dat jullie dit zelf kunnen uitzoeken. Als je nieuw bent, zal ik de juiste richting aangeven, maar we zullen hier niet ingaan op de fijnere details van het beheren van Apple-certificaten, die bovendien constant veranderen. Deze post helpt je op weg.

Mijn applicaties

Je hebt een app in App Store Connect nodig om een ID voor de configuratie te hebben. .xcodebuild.Het profiel en de app-ID verbinden builds van code, prijzen en beschikbaarheid, evenals de TestFlight-configuratie voor het verspreiden van testapps onder gebruikers. Doe geen openbare tests, privé is genoeg als je een kleine groep hebt, een eenvoudige setup en geen extra permissies van Apple nodig hebt.

Initiële profiel

Naast de opzet van de app heb je distributie- en ontwikkelingssleutels nodig, die zijn aangemaakt in de sectie Certificates, Identifiers & Profiles in de Apple Developer-console. Al deze certificaten kunnen worden samengevoegd in het initiële profiel.

Gebruikers die zich moeten authenticeren, hebben de mogelijkheid nodig om certificaten te maken, anders zie je bij de stappen cert en sigh, een fout.

Andere opties

Naast deze eenvoudige methode zijn er andere manieren om certificaten en profielen in te stellen. Dus als je anders werkt, moet je misschien herstructureren. Het belangrijkste is dat je een configuratie nodig hebt .xcodebuild.die verwijst naar de benodigde bestanden, en de sleutel bundel moet toegankelijk zijn op de buildcomputer voor de gebruiker onder wiens naam de runner draait. Voor digitale handtekening gebruiken we fastlane, en als er problemen zijn of je wilt meer weten, bestudeer dan hun details. documentatie over digitale handtekeningen.

In dit voorbeeld gebruik ik een aanpak cert en sigh,, maar voor een echte toepassing is het waarschijnlijk beter match.

Voorbereiding van GitLab en fastlane

Voorbereiding van CI Runner

Als we al deze gegevens hebben verzameld, gaan we verder met de configuratie van de GitLab-runner op het MacOS apparaat. Helaas is het echt alleen mogelijk om iOS-applicaties te maken op MacOS. Maar alles kan veranderen, en als je op wijzigingen in dit gebied wacht, - blijf dan kijken naar projecten zoals xcbuild en isign, en onze interne taak gitlab-ce#57576.

Het instellen van de runner is heel eenvoudig. Volg de actuele instructies voor het configureren van GitLab Runner op macOS.

Opmerking. De runner moet gebruikmaken van een uitvoeringsprogramma shell. Dit is vereist voor het bouwen van iOS op macOS, zodat het rechtstreeks werkt als gebruiker in plaats van via containers. Als je shell, wordt de build en het testen uitgevoerd namens de runner-gebruiker, rechtstreeks op de build-host. Dit is niet zo veilig als containers, dus kijk beter even door de documentatie over beveiliging, zodat je niets mist.

sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
cd ~
gitlab-runner install
gitlab-runner start

De sleutelhanger van Apple moet op deze host zijn ingesteld met toegang tot de sleutels die Xcode nodig heeft voor de build. De eenvoudigste manier om dit te testen, is in te loggen als gebruiker die de build gaat uitvoeren en proberen de build handmatig uit te voeren. Als het systeem toegang tot de sleutelhanger vraagt, kies dan voor "Altijd toestaan" zodat CI werkt. Misschien is het een goed idee om in te loggen en de eerste paar pipelines te observeren, - om ervoor te zorgen dat ze geen toegang tot de sleutelhanger meer vragen. Het probleem is dat Apple ons niet helpt met de automatische modus, maar als je het eenmaal hebt ingesteld, zal alles goedkomen.

fastlane init

Om fastlane in het project te gebruiken, voer je fastlane inituit. Volg gewoon de instructies voor het installeren en uitvoeren van fastlane, vooral in het gedeelte over Gemfile, want we hebben een snelle en voorspelbare uitvoering nodig via de automatische CI-pijplijn.

Voer deze commando's uit in de projectdirectory:

xcode-select --install
sudo gem install fastlane -NV
# Als alternatief met Homebrew
# brew cask install fastlane
fastlane init

fastlane vraagt om een basisconfiguratie en maakt dan in het project een map fastlane aan met drie bestanden:

1. fastlane/Appfile

Hier is niets moeilijk aan. Controleer gewoon of de Apple ID en de app-ID correct zijn ingevoerd.

app_identifier("com.vontrance.flappybird") # De bundelidentifier van je app
apple_id("your-email@your-domain.com") # Je Apple-e-mailadres

2. fastlane/Fastfile

Fastfile bepaalt de bouwstappen. We gebruiken veel ingebouwde mogelijkheden van fastlane, dus dit is ook duidelijk. We creëren één lijn die certificaten verkrijgt, de bouw uitvoert en deze naar TestFlight uploadt. Je kunt dit proces splitsen in verschillende taken indien nodig. Al deze bewerkingen (get_certificates, get_provisioning_profile, gym en upload_to_testflight) zijn al inbegrepen in fastlane.

Acties get_certificates en get_provisioning_profile bedoeld voor de handtekening aanpak cert en sigh,. Als je match of iets anders gebruikt, maak dan aanpassingen.

default_platform(:ios)

platform :ios do
  desc "Bouw de applicatie"
  lane :flappybuild do
    get_certificates
    get_provisioning_profile
    gym
    upload_to_testflight
  end
end

3. fastlane/Gymfile

Dit is een optioneel bestand, maar ik heb het handmatig aangemaakt om de standaard uitvoermap te wijzigen en de uitvoer in de huidige map te plaatsen. Dit vereenvoudigt CI. Als je geïnteresseerd bent, lees dan over gym en zijn parameters in de documentatie.

https://docs.fastlane.tools/actions/gym/

Onze .gitlab-ci.yml

Dus, we hebben een CI-runner voor het project en we zijn klaar om de pipeline te testen. Laten we kijken wat we hebben in .gitlab-ci.yml:

stages:
  - build

variables:
  LC_ALL: "en_US.UTF-8"
  LANG: "en_US.UTF-8"
  GIT_STRATEGY: clone

build:
  stage: build
  script:
    - bundle install
    - bundle exec fastlane flappybuild
  artifacts:
    paths:
    - .\/FlappyBird.ipa

Alles gaat prima! We stellen UTF-8 in voor fastlane, zoals vereist, gebruiken de strategie clone met de uitvoerbare applicatie shell, zodat we een schone werkomgeving voor elke bouw hebben en gewoon aanroepen flappybuild fastlane, zoals hierboven te zien is. Uiteindelijk krijgen we de bouw, handtekening en implementatie van de laatste bouw in TestFlight.

We krijgen ook een artefact en bewaren het met de bouw. Merk op dat het formaat .ipa een ondertekend uitvoerbaar ARM-bestand is dat niet kan worden uitgevoerd in de simulator. Als je uitvoer voor de simulator wilt, voeg gewoon de bouwtarget toe die dit produceert en voeg het dan toe aan het pad naar het artefact.

Andere omgevingsvariabelen

Hier zijn een paar omgevingsvariabelen waarop alles werkt.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD en FASTLANE_SESSION

Voor authenticatie in de App Store en uploaden naar TestFlight is authenticatie voor fastlane nodig. Maak daarvoor een applicatiewachtwoord aan dat wordt gebruikt in CI. Details hier.

Als je tweefactorauthenticatie hebt, maak dan een variabele aan FASTLANE_SESSION (instructies daar ook).

FASTLANE_USER en FASTLANE_PASSWORD

Om cert en sigh, heeft de initialisatieprofiel en certificaten op aanvraag aangeroepen, voer dan variabelen in FASTLANE_USER en FASTLANE_PASSWORD. Details hier. Dit is niet nodig als je een andere handtekeningmethode gebruikt.

Ter conclusie

Bekijk hoe dit allemaal werkt in mijn eenvoudige voorbeeld.

Ik hoop dat dit nuttig was en dat ik je heb geïnspireerd om met iOS-builds in GitLab te werken. Hier zijn nog meer tips voor CI voor fastlane, voor het geval dat. Misschien wil je gebruikmaken van CI_BUILD_ID (voor incrementele builds), om automatisch de versie te verhogen.

Een andere geweldige functie van fastlane is automatische screenshots voor de App Store, die heel eenvoudig in te stellen zijn.

Deel je ervaringen in de reacties en deel ideeën om GitLab te verbeteren voor iOS-app ontwikkeling.

Bron: habr.com