ProHoster > Blog > Uprava > Značilnosti gradnje in dostave aplikacij za iOS

Značilnosti gradnje in dostave aplikacij za iOS

V tem članku delimo izkušnje pri sestavljanju in dostavi iOS aplikacij uporabnikom, ki jih je studio Plarium Krasnodar nabral v procesu odpravljanja napak CI/CD.

Značilnosti gradnje in dostave aplikacij za iOS

Izobraževanje

Vsakdo, ki se tako ali drugače ukvarja z razvojem aplikacij za naprave Apple, je že ocenil kontroverzno priročnost infrastrukture. Težave so povsod: od menija profila razvijalca do orodij za odpravljanje napak in gradnjo.

Na internetu je veliko člankov o "osnovah", zato bomo poskušali izpostaviti glavno stvar. Tukaj je tisto, kar potrebujete za uspešno izdelavo aplikacije:

  • račun razvijalca;
  • naprava, ki temelji na sistemu macOS in deluje kot gradbeni strežnik;
  • ustvarjena potrdilo razvijalca, ki se bo v nadaljevanju uporabljal za podpis vloge;
  • ustvarili aplikacijo z edinstveno ID (opozoriti je treba na pomembnost identifikatorja paketa, ker uporaba ID-ja z nadomestnimi znaki onemogoča uporabo številnih funkcij aplikacije, na primer: povezane domene, potisna obvestila, prijava Apple in druge);
  • profil podpisi aplikacij.

Potrdilo razvijalca je treba ustvariti prek Keychaina v kateri koli napravi macOS. Vrsta certifikata je zelo pomembna. Odvisno od aplikacijskega okolja (razvoj, zagotavljanje kakovosti, uprizoritev, produkcija) se bo razlikovalo (razvoj ali distribucija), kot tudi vrsta profila podpisa aplikacije.

Glavne vrste profilov:

  • Razvoj - namenjen podpisovanju aplikacije razvojne ekipe, uporablja se Razvojni certifikat (ime tipa iPhone Developer: XXXXX);
  • Ad Hoc - namenjen podpisovanju testne aplikacije in interni verifikaciji s strani QA oddelka, uporablja se Distribution certifikat razvijalca (ime tipa iPhone Distribution: XXXXX);
  • App Store - izdaja gradnje za zunanje testiranje prek TestFlight in nalaganje v App Store, uporablja se razvijalčevo potrdilo o distribuciji.

Pri generiranju razvojnih in ad hoc profilov je tudi navedeno seznam naprav, na katerega lahko namestite gradnjo, ki omogoča dodatno omejitev dostopa uporabnikom. V profilu App Store ni seznama naprav, saj nadzor dostopa med zaprtim testiranjem beta izvaja TestFlight, o katerem bomo razpravljali kasneje.

Zaradi jasnosti lahko predstavite profil razvijalca v obliki spodnje tabele. Tako lažje razumemo, katere parametre potrebujemo za montažo in kje jih dobiti.

Značilnosti gradnje in dostave aplikacij za iOS

Skupščina

Za lažje ločevanje sklopov po projektu in okolju uporabljamo imena profilov, kot je ${ProjectName}_${Instance}, to je ime projekta + primerek (odvisno od aplikacijskega okolja: Dev, QA, GD, Staging, Live in tako naprej).

Ko je profil uvožen v gradbeni strežnik, spremeni svoje ime v edinstven ID in se premakne v mapo /Users/$Username/Library/MobileDevice/Provisioning Profiles (Kje $Username ustreza imenu uporabniškega računa gradbenega strežnika).

Datoteko *.ipa lahko zgradite na dva načina - stari (PackageApplication) in sodoben (prek ustvarjanja in izvoza XcAchive). Prva metoda velja za zastarelo, saj je bil od različice 8.3 modul za pakiranje datotek aplikacije odstranjen iz distribucije Xcode. Če ga želite uporabiti, morate kopirati modul iz starega Xcode (različica 8.2 in starejše) v mapo:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

In nato zaženite ukaz:

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

Nato morate zbrati datoteko *.app aplikacije:

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

Kje:

-workspace — pot do projektne datoteke.

-scheme — uporabljena shema, navedena v projektu.

-derivedDataPath — pot za prenos sestavljene aplikacije (*.app).

CODE_SIGN_IDENTITY — ime računa razvijalca, ki ga je mogoče preveriti v Keychainu (iPhone Developer: XXXX XXXXXXX, brez TeamID v oklepaju).

Značilnosti gradnje in dostave aplikacij za iOS

PROVISIONING_PROFILE — ID profila za podpisovanje aplikacije, ki ga pridobimo z ukazom:

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

Če aplikacija uporablja dodaten profil (na primer za potisna obvestila), potem namesto PROVISIONING_PROFILE označite:

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

Nato je treba nastalo datoteko *.app zapakirati v *.ipa. Če želite to narediti, lahko uporabite ukaz, kot je:

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

Vendar pa ta metoda z vidika Apple velja za zastarelo. Pomembno je pridobiti *.ipa z izvozom iz arhiva aplikacije.

Najprej morate zbrati arhiv z ukazom:

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

Razlike so v načinu montaže in možnostih SYNCHRONOUS_SYMBOL_PROCESSING, ki onemogoči razkladanje simbolov v času gradnje.

Nato moramo ustvariti datoteko z izvoznimi nastavitvami:

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

Kje:

$Method — način dostave, ustreza vrsti profila podpisa aplikacije, to pomeni, da bo za razvoj vrednost razvoj, za ad hoc - ad-hoc in za App Store - trgovina z aplikacijami.

$BundleID — ID aplikacije, ki je določen v nastavitvah aplikacije. Preverite lahko z ukazom: 

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId — nastavitve ID-ja profila razvijalca in podpisa, ki so bile uporabljene prej in se morajo ujemati z vrednostmi v nastavitvah izvoza.

$TeamID — desetmestni ID v oklepaju za imenom razvijalca, na primer: iPhone Developer: …… (XXXXXXXXXX); preverite v Keychainu.

Nato z ukazom za izvoz pridobimo potrebno datoteko *.ipa:

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

Dostava

Zdaj je treba zbrano datoteko dostaviti končnemu uporabniku, torej namestiti na napravo.

Obstaja veliko storitev za distribucijo razvojnih in ad hoc gradenj, kot so HockeyApp, AppBlade in druge, vendar bomo v tem članku govorili o samostojnem strežniku za distribucijo aplikacij.

Namestitev aplikacije za iOS poteka v 2 stopnjah:

  1. Prejemanje manifesta namestitve aplikacije prek storitve Items Service.
  2. Namestitev datoteke *.ipa v skladu z informacijami, navedenimi v manifestu prek HTTPS.

Tako moramo najprej ustvariti namestitveni manifest (vrsta datoteke *.plist) z ukazom:

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

Kot lahko vidite, manifest vsebuje skoraj vse parametre, vključene v izdelavo aplikacije.

Različica aplikacije ($AppVersion) lahko preverite z ukazom:

defaults read $ProjectDir/Info CFBundleVersion

Parameter $ipaUrl vsebuje neposredno povezavo za prenos datoteke *.ipa. Od sedme različice sistema iOS je treba aplikacijo namestiti prek HTTPS. V osmi različici se je oblika manifesta nekoliko spremenila: bloki z nastavitvami za ikone aplikacij, kot je

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

Tako je za namestitev aplikacije dovolj preprosta stran HTML s povezavo, kot je ta:

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

Za potrebe oddelkov za razvoj in testiranje je Plarium izdelal lastno aplikacijo za namestitev gradnje, ki nam omogoča:

  • samostojnost in neodvisnost,
  • centralizacija nadzora dostopa in varna namestitev aplikacij preko »začasnih« dinamično ustvarjenih povezav,
  • razširljivo funkcionalnost (to pomeni, da lahko razvojna ekipa po potrebi integrira manjkajoče funkcije v obstoječo aplikacijo).

Testiranje

Zdaj bomo govorili o testiranju aplikacije pred objavo z uporabo testni let.

Zahtevani pogoji za prenos so vrsta podpisnega profila App Store in prisotnost generiranih ključev API.

Aplikacijo lahko prenesete na več načinov:

  • prek Xcode (organizator),
  • prek altoola,
  • prek Application Loaderja za starejše različice Xcode (zdaj Transporter).

Za samodejni prenos se uporablja altool, ki ima tudi dva načina avtorizacije:

  • Geslo za posamezno aplikacijo,
  • API ključ.

Zaželeno je, da aplikacijo prenesete s ključem API.

Če želite pridobiti ključ API, pojdite na povezava in ustvarite ključ. Poleg samega ključa v formatu *.p8 bomo potrebovali še dva parametra: IssuerID in KeyID.

Značilnosti gradnje in dostave aplikacij za iOS

Nato uvozite preneseni ključ v gradbeni strežnik:

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

Preden naložite aplikacijo na TestFlight, morate aplikacijo potrditi, to naredimo z ukazom:

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

kjer je apiKey и apiIssuer imajo vrednosti polj s strani za generiranje ključev API.

Nato po uspešni validaciji naložimo aplikacijo z ukazom --upload-app z enakimi parametri.

Aplikacijo bo Apple preizkusil v enem ali dveh dneh in bo nato na voljo zunanjim preizkuševalcem: po e-pošti jim bodo poslali povezave za namestitev.

Drug način za prenos aplikacije prek altoola je uporaba posebnega gesla za aplikacijo.

Če želite pridobiti geslo za aplikacijo, morate iti na povezava in ga ustvarite v razdelku Varnost.

Značilnosti gradnje in dostave aplikacij za iOS

Nato bi morali ustvariti zapis strežnika gradnje v Keychainu s tem geslom. Od različice 11 Xcode je to mogoče storiti z ukazom:

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

Kje:

$DeveloperName — ime računa razvijalca iOS, ki se uporablja za prijavo v storitve Apple.

$AppPswd — ustvarjeno geslo za aplikacijo.

Nato pridobimo vrednost parametra asc-provider in preverimo uspešnost uvoza gesla z ukazom:

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

Dobimo rezultat:

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

Kot lahko vidite, zahtevana vrednost kratkega imena (asc-provider) sovpada s parametrom $TeamID, ki smo ga uporabili pri gradnji aplikacije.

Za potrditev in nalaganje aplikacije v TestFlight uporabite ukaz: 

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

Kot vrednost parametra -p lahko prevzamete vrednost $AppPswd v nešifrirani (eksplicitni) obliki.

Vendar, kot že omenjeno, je z vidika zmogljivosti bolje izbrati ključ API za avtorizacijo altool, saj imajo različne različice Xcode določene težave (»ne vidi« Keychain, avtorizacijske napake med nalaganjem itd.).

To je pravzaprav vse. Vsem udeleženim želim uspešne gradnje in izdaje brez težav v App Store.

Vir: www.habr.com

Dodaj komentar