Funksjes fan it bouwen en leverjen fan iOS-applikaasjes

Yn dit artikel diele wy de ûnderfining fan it gearstallen en leverjen fan iOS-applikaasjes oan brûkers, dy't de Plarium Krasnodar-studio hat sammele yn it proses fan debuggen fan CI / CD.

Funksjes fan it bouwen en leverjen fan iOS-applikaasjes

Tarieding fan

Elke persoan dy't op ien of oare manier belutsen is by de ûntwikkeling fan applikaasjes foar Apple-apparaten hat it kontroversjele gemak fan 'e ynfrastruktuer al wurdearre. Swierrichheden wurde oeral fûn: fan it ûntwikkeldersprofylmenu oant de debug- en bouwark.

D'r binne genôch artikels oer de "basis" op it ynternet, dus wy sille besykje it wichtichste te markearjen. Hjir is wat jo nedich hawwe om jo applikaasje mei súkses te bouwen:

  • developer account;
  • in macOS-basearre apparaat fungearret as in build-tsjinner;
  • oanmakke developer sertifikaat, dy't fierder brûkt wurde om de oanfraach te ûndertekenjen;
  • oanmakke applikaasje mei unyk ID (it belang fan 'e bondelidentifikaasje moat wurde opmurken, om't it gebrûk fan jokerteken-ID it ûnmooglik makket om in protte funksjes fan' e applikaasje te brûken, bygelyks: Associated Domains, Push Notifications, Apple Sign In en oaren);
  • profyl applikaasje hantekeningen.

In ûntwikkelderssertifikaat moat wurde oanmakke fia Keychain op elk macOS-apparaat. It type sertifikaat is heul wichtich. Ofhinklik fan 'e applikaasjeomjouwing (Dev, QA, Staging, Produksje) sil it ferskille (ûntwikkeling as distribúsje), lykas it type hântekeningprofyl foar applikaasje.

De wichtichste typen fan profilen:

  • Untwikkeling - bedoeld foar it ûndertekenjen fan de applikaasje fan it ûntwikkelteam, in Untwikkelingssertifikaat wurdt brûkt (type namme iPhone Untwikkelder: XXXXX);
  • Ad Hoc - bedoeld foar it ûndertekenjen fan in testapplikaasje en ynterne ferifikaasje troch de QA-ôfdieling, it distribúsjesertifikaat fan 'e ûntwikkelder wurdt brûkt (typenamme iPhone-distribúsje: XXXXX);
  • App Store - release build foar eksterne testen fia TestFlight en upload nei de App Store, it distribúsjesertifikaat fan 'e ûntwikkelder wurdt brûkt.

By it generearjen fan Untwikkelings- en Ad Hoc-profilen wurdt it ek oanjûn apparaat list, wêrop jo in build kinne ynstallearje, wêrtroch jo tagong kinne foar brûkers fierder beheine. D'r is gjin list mei apparaten yn it App Store-profyl, om't tagongskontrôle tidens sletten beta-testen wurdt behannele troch TestFlight, dy't letter sil wurde besprutsen.

Foar dúdlikens kinne jo it profyl fan de ûntwikkelders presintearje yn 'e foarm fan in tabel hjirûnder. Dit makket it makliker om te begripen hokker parameters wy nedich binne foar assemblage en wêr't se se kinne krije.

Funksjes fan it bouwen en leverjen fan iOS-applikaasjes

Assembly

Om it makliker te meitsjen om gearkomsten te skieden troch projekt en omjouwing, brûke wy profylnammen lykas ${ProjectName}_${Instance}, dat is projektnamme + eksimplaar (hinget ôf fan 'e applikaasjeomjouwing: Dev, QA, GD, Staging, Live, ensfh.).

As ymportearre nei de build-tsjinner, feroaret it profyl syn namme nei in unike ID en wurdt ferpleatst nei de map /Users/$Username/Library/MobileDevice/Provisioning Profiles (Wêr $Username komt oerien mei de brûkersnamme fan 'e build-tsjinner).

D'r binne twa manieren om in *.ipa-bestân te bouwen - legacy (PackageApplication) en modern (fia XcAchive oanmeitsjen en eksportearje). De earste metoade wurdt beskôge as ferâldere, om't sûnt ferzje 8.3 de app-bestânferpakkingsmodule is fuortsmiten fan 'e Xcode-distribúsje. Om it te brûken, moatte jo de module kopiearje fan 'e âlde Xcode (ferzje 8.2 en earder) nei de map:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

En dan it kommando útfiere:

chmod +x /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/*

Folgjende moatte jo it *.app-bestân fan 'e applikaasje sammelje:

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

Wêr:

-workspace - paad nei it projektbestân.

-scheme - it brûkte skema, spesifisearre yn it projekt.

-derivedDataPath - paad om de gearstalde applikaasje (*.app) te downloaden.

CODE_SIGN_IDENTITY - de namme fan it ûntwikkeldersakkount, dat kin wurde ferifiearre yn Keychain (iPhone Untwikkelder: XXXX XXXXXXX, sûnder TeamID yn heakjes).

Funksjes fan it bouwen en leverjen fan iOS-applikaasjes

PROVISIONING_PROFILE - Profile ID foar ûndertekening fan de applikaasje, dy't kin wurde krigen mei it kommando:

cd "/Users/$Username/Library/MobileDevice/Provisioning Profiles/" && find *.mobileprovision -type f | xargs grep -li ">${ProjectName}_${Instance}<" | sed -e 's/.mobileprovision//'

As de applikaasje in ekstra profyl brûkt (bygelyks foar push-notifikaasjes), dan ynstee fan PROVISIONING_PROFILE oanjaan:

APP_PROFILE=”$AppProfile” 
EXTENSION_PROFILE=”$ExtProfile” 

Folgjende, de resultearjende *.app triem moat wurde ferpakt yn *.ipa. Om dit te dwaan kinne jo in kommando brûke lykas:

/usr/bin/xcrun --sdk iphoneos PackageApplication 
-v $(find "$ProjectDir/build/Build/Products/Release-iphoneos" -name "*.app") 
-o "$ProjectDir/$ProjectName_$Instance.ipa"

Dizze metoade wurdt lykwols beskôge as ferâldere út Apple's eachpunt. It is relevant om *.ipa te krijen troch te eksportearjen út it applikaasje-argyf.

Earst moatte jo it argyf sammelje mei it kommando:

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 ferskillen lizze yn 'e gearstalling metoade en opsjes SYNCHRONOUS_SYMBOL_PROCESSING, dy't it laden fan symboalen útskeakelje by it bouwen.

Folgjende moatte wy in bestân generearje mei eksportynstellingen:

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

Wêr:

$Method - leveringsmetoade, komt oerien mei it type fan hantekeningprofyl fan 'e applikaasje, dat is, foar Untwikkeling sil de wearde ûntwikkeling wêze, foar Ad Hoc - ad-hoc, en foar App Store - app-store.

$BundleID - Applikaasje-ID, dat is oantsjutte yn 'e applikaasje-ynstellingen. Jo kinne kontrolearje mei it kommando:

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId - Ynstellings foar ûntwikkeldersnamme en hantekeningprofyl ID dy't earder waarden brûkt en moatte oerienkomme mei de wearden yn 'e eksportynstellingen.

$TeamID - tsien-sifers ID yn heakjes nei de namme fan de ûntwikkelder, foarbyld: iPhone-ûntwikkelder: …… (XXXXXXXXXX); kin wurde kontrolearre yn Keychain.

Folgjende, mei it eksportkommando, krije wy it nedige *.ipa-bestân:

xcodebuild 
-exportArchive 
-archivePath $ProjectDir/build/$ProjectName.xcarchive 
-exportPath $ProjectDir 
-exportOptionsPlist $ExportSettings

Shipping info

No moat it sammele bestân wurde levere oan de einbrûker, dat is ynstalleare op it apparaat.

D'r binne in protte tsjinsten foar it fersprieden fan Untwikkeling en Ad Hoc builds, lykas HockeyApp, AppBlade en oaren, mar yn dit artikel sille wy prate oer in standalone tsjinner foar it fersprieden fan applikaasjes.

It ynstallearjen fan de applikaasje foar iOS fynt plak yn 2 stadia:

  1. Ûntfange de applikaasje ynstallaasje manifest fia de Items Service.
  2. Ynstallaasje fan it *.ipa-bestân neffens de ynformaasje oantsjutte yn it manifest fia HTTPS.

Sa moatte wy earst in ynstallaasjemanifest (bestânstype *.plist) generearje mei it kommando:

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>
EOF

Sa't jo sjen kinne, befettet it manifest hast alle parameters belutsen by it bouwen fan 'e applikaasje.

Applikaasje ferzje ($AppVersion) kin kontrolearre wurde mei it kommando:

defaults read $ProjectDir/Info CFBundleVersion

Parameter $ipaUrl befettet in direkte keppeling om it *.ipa-bestân te downloaden. Fan 'e sânde ferzje fan iOS moat de applikaasje ynstalleare wurde fia HTTPS. Yn 'e achtste ferzje is it formaat fan it manifest wat feroare: blokken mei ynstellings foar applikaasje-ikoanen lykas

<images>
   <image>...</image>
</images>

Sa, om de applikaasje te ynstallearjen, is in ienfâldige HTML-side mei in keppeling lykas dizze genôch:

itms-services://?action=download-manifest&url=https://$ServerUrl/$ProjectName/$Instance/iOS/$AppVersion/manifest.plist

Foar de behoeften fan 'e ûntwikkelings- en testôfdielingen hat Plarium in eigen build-ynstallaasjeapplikaasje makke, dy't ús:

  • autonomy en ûnôfhinklikens,
  • sintralisaasje fan tagongskontrôle en feilige ynstallaasje fan applikaasjes fia "tydlike" dynamysk oanmakke keppelings,
  • útwreidbere funksjonaliteit (dat is, it ûntwikkelteam kin, as it nedich is, ûntbrekkende funksjes yntegrearje yn in besteande applikaasje).

Testing

No sille wy prate oer pre-release testen fan de applikaasje mei help TestFlight.

Fereaske betingsten foar it downloaden binne it type App Store-hantekeningprofyl en de oanwêzigens fan generearre API-kaaien.

D'r binne ferskate manieren om de applikaasje te downloaden:

  • fia Xcode (Organisator),
  • fia altool,
  • fia Application Loader foar âldere ferzjes fan Xcode (no Transporter).

Foar automatyske ynlaad wurdt altool brûkt, dy't ek twa autorisaasjemetoaden hat:

  • App-spesifike wachtwurd,
  • API Key.

It is better om de applikaasje te downloaden mei de API-kaai.

Om de API-kaai te krijen, gean nei link en generearje in kaai. Neist de kaai sels yn *.p8 opmaak, wy sille nedich twa parameters: IssuerID en KeyID.

Funksjes fan it bouwen en leverjen fan iOS-applikaasjes

Ymportearje dan de ynladen kaai nei de build-tsjinner:

mkdir -p ~/.appstoreconnect/private_keys
mv ~/Downloads/AuthKey_${KeyID}.p8 ~/.appstoreconnect/private_keys/

Foardat jo de applikaasje uploade nei TestFlight, moatte jo de applikaasje falidearje, wy dogge dit mei it kommando:

xcrun altool 
--validate-app 
-t ios 
-f $(find "$ProjectDir" -name "*.ipa") 
--apiKey “$KeyID” 
--apiIssuer “$IssuerID” 

Wêr apiKey и apiIssuer hawwe fjildwearden fan 'e API-kaaigeneraasjepagina.

Folgjende, nei suksesfolle falidaasje, laden wy de applikaasje mei it kommando --upload-app mei deselde parameters.

De applikaasje sil binnen ien of twa dagen troch Apple wurde hifke en sil dan beskikber wurde foar eksterne testers: se sille e-maile keppelings foar ynstallaasje.

In oare manier om in applikaasje fia altool te downloaden is om App-spesifike wachtwurd te brûken.

Om it app-spesifike wachtwurd te krijen moatte jo nei link en generearje it yn 'e Feiligens seksje.

Funksjes fan it bouwen en leverjen fan iOS-applikaasjes

Dêrnei moatte jo in build-serverrecord yn Keychain meitsje mei dit wachtwurd. Fan ferzje 11 fan Xcode kin dit dien wurde mei it kommando:

xcrun altool --store-password-in-keychain-item "Altool" -u "$DeveloperName" -p $AppPswd

Wêr:

$DeveloperName - de namme fan it iOS-ûntwikkeldersakkount dat wurdt brûkt om oan te melden by Apple-tsjinsten.

$AppPswd - oanmakke app-spesifike wachtwurd.

Dêrnei krije wy de wearde fan 'e parameter asc-provider en kontrolearje it sukses fan' e wachtwurd ymportearje mei it kommando:

xcrun altool --list-providers -u "$DeveloperName" -p "@keychain:Altool"

Wy krije de útfier:

Provider listing:
- Long Name - - Short Name -
XXXXXXX        XXXXXXXXX

Sa't jo sjen kinne, komt de fereaske koarte nammewearde (asc-provider) oerien mei de $TeamID-parameter dy't wy brûkten by it bouwen fan 'e applikaasje.

Om de applikaasje te falidearjen en te laden yn TestFlight, brûk it kommando:

xcrun altool 
--(validate|upload)-app   
-f $(find "$ProjectDir" -name "*.ipa") 
-u "$DeveloperName" 
-p "@keychain:Altool" 

As parameter wearde -p jo kinne nimme de wearde $AppPswd yn net-fersifere (eksplisite) foarm.

Lykwols, lykas al neamd, út it eachpunt fan prestaasjes, is it better om te kiezen API Key foar altool autorisaasje, sûnt ferskillende ferzjes fan Xcode hawwe bepaalde problemen ("net sjen" Keychain, autorisaasje flaters by upload, ensfh).

Dat is alles, eins. Ik winskje elkenien belutsen suksesfolle builds en probleemfrije releases yn 'e App Store.

Boarne: www.habr.com

Add a comment