In dit artikel delen we de ervaring met het samenstellen en leveren van iOS-applicaties aan gebruikers, die de studio van Plarium Krasnodar heeft verzameld tijdens het debuggen van CI/CD.
Opleiding
Iedereen die op een of andere manier betrokken is bij de ontwikkeling van applicaties voor Apple-apparaten heeft het controversiële gemak van de infrastructuur al gewaardeerd. Moeilijkheden zijn overal te vinden: van het ontwikkelaarsprofielmenu tot de debug- en buildtools.
Er zijn veel artikelen over de 'basis' op internet, dus we zullen proberen het belangrijkste te benadrukken. Dit is wat u nodig heeft om uw applicatie succesvol te bouwen:
- ;
- een macOS-gebaseerd apparaat dat fungeert als buildserver;
- gegenereerd , die verder zal worden gebruikt om de aanvraag te ondertekenen;
- applicatie gemaakt met uniek (het belang van de bundelidentificatie moet worden opgemerkt, omdat het gebruik van een wildcard-ID het onmogelijk maakt om veel functies van de applicatie te gebruiken, bijvoorbeeld: geassocieerde domeinen, pushmeldingen, Apple Sign In en andere);
- handtekeningen van applicaties.
Op elk macOS-apparaat moet via Keychain een ontwikkelaarscertificaat worden gegenereerd. Het type certificaat is erg belangrijk. Afhankelijk van de applicatieomgeving (Dev, QA, Staging, Production) zal dit verschillen (Ontwikkeling of Distributie), evenals het type handtekeningprofiel van de applicatie.
Belangrijkste soorten profielen:
- Ontwikkeling - bedoeld voor het ondertekenen van de aanvraag van het ontwikkelteam, er wordt gebruik gemaakt van een Ontwikkelcertificaat (typenaam iPhone Developer: XXXXX);
- Ad Hoc - bedoeld voor het ondertekenen van een testaanvraag en interne verificatie door de afdeling QA, er wordt gebruik gemaakt van het Distributiecertificaat van de ontwikkelaar (typenaam iPhone Distributie: XXXXX);
- App Store - release build voor extern testen via TestFlight en uploaden naar de App Store, het distributiecertificaat van de ontwikkelaar wordt gebruikt.
Bij het genereren van Development- en Ad Hoc-profielen wordt dit ook aangegeven , waarop u een build kunt installeren, waarmee u de toegang voor gebruikers verder kunt beperken. Er is geen lijst met apparaten in het App Store-profiel, omdat de toegangscontrole tijdens gesloten bètatests wordt afgehandeld door TestFlight, wat later zal worden besproken.
Voor de duidelijkheid kunt u het profiel van de ontwikkelaar hieronder in de vorm van een tabel weergeven. Dit maakt het gemakkelijker om te begrijpen welke parameters we nodig hebben voor de montage en waar we deze vandaan kunnen halen.
montage
Om het gemakkelijker te maken om samenstellingen te scheiden op project en omgeving, gebruiken we profielnamen zoals ${ProjectName}_${Instance}, dat wil zeggen projectnaam + instantie (afhankelijk van de applicatieomgeving: Dev, QA, GD, Staging, Live, enzovoort).
Wanneer het profiel naar de buildserver wordt geïmporteerd, verandert de naam in een unieke ID en wordt het naar de map verplaatst /Users/$Username/Library/MobileDevice/Provisioning Profiles (Waar $Username komt overeen met de gebruikersaccountnaam van de buildserver).
Er zijn twee manieren om een *.ipa-bestand te bouwen: verouderd (PackageApplication) en modern (via het maken en exporteren van XcAchive). De eerste methode wordt als verouderd beschouwd, aangezien sinds versie 8.3 de app-bestandsverpakkingsmodule uit de Xcode-distributie is verwijderd. Om het te gebruiken, moet je de module van de oude Xcode (versie 8.2 en eerder) naar de map kopiëren:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/
En voer vervolgens het commando uit:
chmod +x /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/*Vervolgens moet u het *.app-bestand van de applicatie verzamelen:
xcodebuild
-workspace $ProjectDir/$ProjectName.xcworkspace
-scheme $SchemeName
-sdk iphoneos
build
-configuration Release
-derivedDataPath build
CODE_SIGN_IDENTITY=”$DevAccName”
PROVISIONING_PROFILE=”$ProfileId”
DEPLOYMENT_POSTPROCESSING=YES
SKIP_INSTALL=YES
ENABLE_BITCODE=NO
Waar:
-workspace — pad naar het projectbestand.
-scheme — het gebruikte schema, gespecificeerd in het project.
-derivedDataPath — pad om de samengestelde applicatie te downloaden (*.app).
CODE_SIGN_IDENTITY — de naam van het ontwikkelaarsaccount, die kan worden geverifieerd in Keychain (iPhone-ontwikkelaar: XXXX XXXXXXX, zonder TeamID tussen haakjes).
PROVISIONING_PROFILE — Profiel-ID voor het ondertekenen van de aanvraag, die kan worden verkregen met de opdracht:
cd "/Users/$Username/Library/MobileDevice/Provisioning Profiles/" && find *.mobileprovision -type f | xargs grep -li ">${ProjectName}_${Instance}<" | sed -e 's/.mobileprovision//'
Als de applicatie een extra profiel gebruikt (bijvoorbeeld voor pushmeldingen), dan in plaats van PROVISIONING_PROFILE aangeven:
APP_PROFILE=”$AppProfile”
EXTENSION_PROFILE=”$ExtProfile” Vervolgens moet het resulterende *.app-bestand worden verpakt in *.ipa. Om dit te doen, kunt u een commando gebruiken zoals:
/usr/bin/xcrun --sdk iphoneos PackageApplication
-v $(find "$ProjectDir/build/Build/Products/Release-iphoneos" -name "*.app")
-o "$ProjectDir/$ProjectName_$Instance.ipa"Deze methode wordt vanuit het standpunt van Apple echter als achterhaald beschouwd. Het is relevant om *.ipa te verkrijgen door te exporteren vanuit het applicatiearchief.
Eerst moet je het archief verzamelen met de opdracht:
xcodebuild
-workspace $ProjectDir/$ProjectName.xcworkspace
-scheme $SchemeName
-sdk iphoneos
-configuration Release
archive
-archivePath $ProjectDir/build/$ProjectName.xcarchive
CODE_SIGN_IDENTITY=”$DevAccName”
PROVISIONING_PROFILE=”$ProfileId”
ENABLE_BITCODE=NO
SYNCHRONOUS_SYMBOL_PROCESSING=FALSE
De verschillen zitten in de montagewijze en mogelijkheden SYNCHRONOUS_SYMBOL_PROCESSING, waarmee het lossen van symbolen tijdens het bouwen wordt uitgeschakeld.
Vervolgens moeten we een bestand genereren met exportinstellingen:
ExportSettings="$ProjectDir/exportOptions.plist"
cat << EOF > $ExportSettings
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>compileBitcode</key>
<false/>
<key>uploadBitcode</key>
<false/>
<key>uploadSymbols</key>
<false/>
<key>method</key>
<string>$Method</string>
<key>provisioningProfiles</key>
<dict>
<key>$BundleID</key>
<string>$ProfileId</string>
</dict>
<key>signingCertificate</key>
<string>$DevAccName</string>
<key>signingStyle</key>
<string>manual</string>
<key>stripSwiftSymbols</key>
<true/>
<key>teamID</key>
<string>$TeamID</string>
<key>thinning</key>
<string><none></string>
</dict>
</plist>
EOF
Waar:
$Method — leveringsmethode, komt overeen met het type handtekeningprofiel van de applicatie, dat wil zeggen dat voor Ontwikkeling de waarde ontwikkeling zal zijn, voor Ad Hoc - ad-hoc, en voor App Store - app-store.
$BundleID — Applicatie-ID, die is opgegeven in de applicatie-instellingen. U kunt dit controleren met het commando:
defaults read $ProjectDir/Info CFBundleIdentifier
$DevAccName и $ProfileId — ontwikkelaarnaam en handtekeningprofiel-ID-instellingen die eerder zijn gebruikt en moeten overeenkomen met de waarden in de exportinstellingen.
$TeamID — ID van tien cijfers tussen haakjes achter de naam van de ontwikkelaar, bijvoorbeeld: iPhone-ontwikkelaar: …… (XXXXXXXXXX); kan worden ingecheckt in Keychain.
Vervolgens verkrijgen we met behulp van de exportopdracht het benodigde *.ipa-bestand:
xcodebuild
-exportArchive
-archivePath $ProjectDir/build/$ProjectName.xcarchive
-exportPath $ProjectDir
-exportOptionsPlist $ExportSettingsLevering
Nu moet het verzamelde bestand aan de eindgebruiker worden afgeleverd, dat wil zeggen op het apparaat worden geïnstalleerd.
Er zijn veel services voor het distribueren van ontwikkelings- en ad-hocbuilds, zoals HockeyApp, AppBlade en anderen, maar in dit artikel zullen we het hebben over een zelfstandige server voor het distribueren van applicaties.
Het installeren van de applicatie voor iOS gebeurt in 2 fasen:
- Het ontvangen van het installatiemanifest van de applicatie via de Items Service.
- Installatie van het *.ipa-bestand volgens de informatie gespecificeerd in het manifest via HTTPS.
We moeten dus eerst een installatiemanifest (bestandstype *.plist) genereren met de opdracht:
cat << EOF > $manifest
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>$ipaUrl</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>$BundleID</string>
<key>bundle-version</key>
<string>$AppVersion</string>
<key>kind</key>
<string>software</string>
<key>title</key>
<string>$ProjectName_$Instance</string>
<key>subtitle</key>
<string>$Instance</string>
</dict>
</dict>
</array>
</dict>
</plist>
EOFZoals u kunt zien, bevat het manifest bijna alle parameters die betrokken zijn bij het bouwen van de applicatie.
Applicatie versie ($AppVersion) kan worden gecontroleerd met het commando:
defaults read $ProjectDir/Info CFBundleVersion
Parameter $ipaUrl bevat een directe link om het *.ipa-bestand te downloaden. Vanaf de zevende versie van iOS moet de applicatie via HTTPS worden geïnstalleerd. In de achtste versie is het formaat van het manifest enigszins veranderd: blokken met instellingen voor applicatiepictogrammen zoals
<images>
<image>...</image>
</images>Om de applicatie te installeren is dus een eenvoudige HTML-pagina met een link als deze voldoende:
itms-services://?action=download-manifest&url=https://$ServerUrl/$ProjectName/$Instance/iOS/$AppVersion/manifest.plistVoor de behoeften van de ontwikkelings- en testafdelingen heeft Plarium zijn eigen build-installatieapplicatie gemaakt, die ons het volgende biedt:
- autonomie en onafhankelijkheid,
- centralisatie van toegangscontrole en veilige installatie van applicaties via “tijdelijke” dynamisch gecreëerde koppelingen,
- uitbreidbare functionaliteit (dat wil zeggen dat het ontwikkelteam, indien nodig, ontbrekende functies kan integreren in een bestaande applicatie).
Testen
Nu zullen we het hebben over het pre-release testen van de applicatie die gebruikt wordt .
Vereiste voorwaarden voor het downloaden zijn het handtekeningprofieltype van de App Store en de aanwezigheid van gegenereerde API-sleutels.
Er zijn verschillende manieren om de applicatie te downloaden:
- via Xcode (Organisator),
- via altool,
- via Application Loader voor oudere versies van Xcode (nu Transporter).
Voor automatisch downloaden wordt altool gebruikt, dat ook over twee autorisatiemethoden beschikt:
- App-specifiek wachtwoord,
- API sleutel.
Het verdient de voorkeur om de applicatie te downloaden met behulp van de API Key.
Ga naar om de API-sleutel te verkrijgen en genereer een sleutel. Naast de sleutel zelf in *.p8-formaat hebben we twee parameters nodig: IssuerID en KeyID.
Importeer vervolgens de gedownloade sleutel naar de buildserver:
mkdir -p ~/.appstoreconnect/private_keys
mv ~/Downloads/AuthKey_${KeyID}.p8 ~/.appstoreconnect/private_keys/Voordat u de applicatie uploadt naar TestFlight, moet u de applicatie valideren, dit doen we met het commando:
xcrun altool
--validate-app
-t ios
-f $(find "$ProjectDir" -name "*.ipa")
--apiKey “$KeyID”
--apiIssuer “$IssuerID”
Где apiKey и apiIssuer hebben veldwaarden van de pagina voor het genereren van API-sleutels.
Vervolgens laden we, na succesvolle validatie, de applicatie met de opdracht --upload-app met dezelfde parameters.
De applicatie wordt binnen één of twee dagen door Apple getest en komt dan beschikbaar voor externe testers: zij krijgen per e-mail links voor installatie.
Een andere manier om een applicatie via altool te downloaden is door een app-specifiek wachtwoord te gebruiken.
Om het app-specifieke wachtwoord te krijgen, moet u naar gaan en genereer het in de sectie Beveiliging.
Vervolgens moet u met dit wachtwoord een buildserverrecord in Keychain maken. Vanaf versie 11 van Xcode kan dit met het commando:
xcrun altool --store-password-in-keychain-item "Altool" -u "$DeveloperName" -p $AppPswdWaar:
$DeveloperName — de naam van het iOS-ontwikkelaarsaccount dat wordt gebruikt om in te loggen bij Apple-services.
$AppPswd — gegenereerd app-specifiek wachtwoord.
Vervolgens krijgen we de waarde van de asc-provider parameter en controleren we het succes van de wachtwoordimport met de opdracht:
xcrun altool --list-providers -u "$DeveloperName" -p "@keychain:Altool"We krijgen de uitvoer:
Provider listing:
- Long Name - - Short Name -
XXXXXXX XXXXXXXXXZoals u kunt zien, valt de vereiste waarde voor de korte naam (asc-provider) samen met de parameter $TeamID die we hebben gebruikt bij het bouwen van de applicatie.
Om de applicatie te valideren en in TestFlight te laden, gebruikt u de opdracht:
xcrun altool
--(validate|upload)-app
-f $(find "$ProjectDir" -name "*.ipa")
-u "$DeveloperName"
-p "@keychain:Altool"
Als parameterwaarde -p je kunt de waarde aannemen $AppPswd in niet-versleutelde (expliciete) vorm.
Zoals eerder vermeld, is het vanuit het oogpunt van prestaties echter beter om API Key te kiezen voor altool-autorisatie, aangezien verschillende versies van Xcode bepaalde problemen hebben ("ziet sleutelhanger niet", autorisatiefouten tijdens het uploaden, enz.).
Dat is eigenlijk alles. Ik wens alle betrokkenen succesvolle builds en probleemloze releases in de App Store.
Bron: www.habr.com