Szeretnék beszélni a folyamatos integrációról és mobilalkalmazások szállításáról a fastlane használatával. Hogyan implementáljuk a CI/CD-t az összes mobilalkalmazáson, hogyan jutottunk el oda, és mi történt végül.
Már van elég anyag a hálózaton az eszközön, ami az elején nagyon hiányzott, ezért szándékosan nem írom le részletesen az eszközt, csak utalok arra, ami akkor volt:
A cikk két részből áll:
- A mobil CI/CD megjelenésének háttere a vállalatnál
- Műszaki megoldás a CI/CD bevezetéséhez N-alkalmazásokhoz
Az első rész inkább a régi idők nosztalgiája, a második pedig egy élmény, amit magadra is alkalmazhatsz.
Történelmileg így történt
2015. év
Nemrég kezdtünk mobilalkalmazásokat fejleszteni, akkor még semmit sem tudtunk a folyamatos integrációról, a DevOps-ról és egyéb divatos dolgokról. Minden alkalmazásfrissítést maga a fejlesztő gurított ki a gépéről. És ha az Android esetében ez meglehetősen egyszerű - összeszerelve, aláírva .apk és feltöltötte a Google Developer Console-ra, majd iOS-re az akkori Xcode-on keresztüli terjesztési eszköz remek estéket hagyott nekünk - az archívum letöltési kísérletei gyakran hibával végződtek, és újra kellett próbálkoznunk. Kiderült, hogy a legfejlettebb fejlesztő nem ír havonta többször kódot, hanem kiadja az alkalmazást.
2016. év
Felnőttünk, már voltak gondolataink, hogyan szabadítsuk fel a fejlesztőket egy teljes naptól egy kiadásra, és megjelent egy második alkalmazás is, ami csak még inkább az automatizálás felé lökött minket. Ugyanebben az évben telepítettük először a Jenkinst, és írtunk egy csomó ijesztő szkriptet, amelyek nagyon hasonlítanak azokhoz, amelyeket a fastlane a dokumentációjában mutat.
$ xcodebuild clean archive -archivePath build/MyApp
-scheme MyApp
$ xcodebuild -exportArchive
-exportFormat ipa
-archivePath "build/MyApp.xcarchive"
-exportPath "build/MyApp.ipa"
-exportProvisioningProfile "ProvisioningProfileName"
$ cd /Applications/Xcode.app/Contents/Applications/Application Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Versions/A/Support/
$ ./altool —upload-app
-f {abs path to your project}/build/{release scheme}.ipa
-u "[email protected]"
-p "PASS_APPLE_ID"Sajnos eddig csak a fejlesztőink tudták, hogyan működnek ezek a szkriptek, és miért van szükség erre a végtelen kulcshalmazra, és amikor ismét elromlott valami, megkapták a „pompás estéket” a naplók elemzésére.
2017. év
Idén megtanultuk, hogy létezik olyan, hogy fastlane. Nem volt annyi információ, mint most – hogyan kell elindítani, hogyan kell használni. Maga az eszköz pedig akkor még durva volt: az állandó hibák csak csalódást okoztak nekünk, és nehéz volt elhinni a varázslatos automatizálást, amit ígértek.
A fastlane magban található fő segédprogramok azonban igen gym и pilot, sikerült elindítanunk.
A forgatókönyveinket kicsit javítottuk.
$ fastlane gym —-workspace "Example.xcworkspace"
--scheme "AppName"
—-buildlog_path "/tmp"
-—cleanJavítottak, már csak azért is, mert nem minden szükséges paraméter xcodebuild, jeleznie kell - gym önállóan megérti, hol és mi rejlik. A további finomhangolás érdekében pedig ugyanazokat a gombokat adhatja meg, mint az in xcodebuild, csak a billentyűk elnevezése világosabb.
Ezúttal az edzőteremnek és a beépített xcpretty formázónak köszönhetően az építési naplók sokkal olvashatóbbá váltak. Ezzel kezdett időt megtakarítani a törött szerelvények kijavítására, és néha a kiadási csapat egyedül is rájött.
Sajnos összeszerelési sebesség mérések xcodebuild и gym Nem mi csináltuk, de megbízunk a dokumentációban – akár 30%-os gyorsítással.
Egyetlen folyamat minden alkalmazáshoz
2018-as év és jelen
2018-ra az alkalmazások elkészítésének és bevezetésének folyamata teljesen átkerült a Jenkinshez, a fejlesztők leállították a kiadást a gépeikről, és csak a kiadási csapatnak volt joga a kiadásra.
Már korábban is szerettük volna javítani a tesztek és a statikus elemzések elindítását, és szkriptjeink egyre nőttek. Az alkalmazásainkkal együtt nőtt és változott. Akkoriban körülbelül 10 alkalmazás volt, tekintve, hogy két platformunk van, ez körülbelül 20 „élő” szkriptet jelent.
Minden alkalommal, amikor új lépést akartunk hozzáadni a szkripthez, be kellett másolnunk a darabokat az összes shell szkriptbe. Talán dolgozhattunk volna körültekintőbben is, de az ilyen változtatások gyakran gépelési hibákkal végződtek, amiből a kiadócsapat estékbe torkollott, hogy kijavítsák a szkripteket, és kiderítsék, melyik okos fickó adta hozzá ezt a parancsot, és mit is csinál valójában. Általánosságban elmondható, hogy az egyik platform összeállításának szkriptjei legalább valamelyest hasonlóak lennének. Bár ők biztosan ugyanazt csinálták.
Egy új alkalmazás folyamatának elindításához egy napot kellett töltenie a szkriptek „friss” verziójának kiválasztásával, hibakeresésével és kimondásával, hogy „igen, működik”.
2018 nyarán ismét a még fejlődő gyorssáv felé néztünk.
1. feladat: foglalja össze a szkript összes lépését, és írja át őket a Fastfile-ba
Amikor elkezdtük, a forgatókönyveink úgy néztek ki, mint egy lábtörlő, amely az összes lépést és mankót egy héjszkriptben tartalmazza a Jenkinsben. Még nem tértünk át a csővezetékre és a szakaszonkénti felosztásra.
Megnéztük, hogy mi van, és azonosítottunk 4 lépést, amelyek megfelelnek a CI/CD-nk leírásának:
- építés - függőségek telepítése, archívum összeállítása,
- teszt – fejlesztői egységtesztek futtatása, lefedettség kiszámítása,
- szonár - elindítja az összes lintert és jelentéseket küld a SonarQube-nak,
- telepíteni — műtermék küldése alfára (TestFlight).
És ha nem megy bele a részletekbe, kihagyva a műveleteknél használt billentyűket, akkor ezt a Fastfile-t kapja:
default_platform(:ios)
platform :ios do
before_all do
unlock
end
desc "Build stage"
lane :build do
match
prepare_build
gym
end
desc "Prepare build stage: carthage and cocoapods"
lane :prepare_build do
pathCartfile = ""
Dir.chdir("..") do
pathCartfile = File.join(Dir.pwd, "/Cartfile")
end
if File.exist?(pathCartfile)
carthage
end
pathPodfile = ""
Dir.chdir("..") do
pathPodfile = File.join(Dir.pwd, "/Podfile")
end
if File.exist?(pathPodfile)
cocoapods
end
end
desc "Test stage"
lane :test do
scan
xcov
end
desc "Sonar stage (after run test!)"
lane :run_sonar do
slather
lizard
swiftlint
sonar
end
desc "Deploy to testflight stage"
lane :deploy do
pilot
end
desc "Unlock keychain"
private_lane :unlock do
pass = ENV['KEYCHAIN_PASSWORD']
unlock_keychain(
password: pass
)
end
endValójában az első Fastfile szörnyűnek bizonyult, figyelembe véve a még mindig szükséges mankókat és a helyettesített paraméterek számát:
lane :build do
carthage(
command: "update",
use_binaries: false,
platform: "ios",
cache_builds: true)
cocoapods(
clean: true,
podfile: "./Podfile",
use_bundle_exec: false)
gym(
workspace: "MyApp.xcworkspace",
configuration: "Release",
scheme: "MyApp",
clean: true,
output_directory: "/build",
output_name: "my-app.ipa")
end
lane :deploy do
pilot(
username: "[email protected]",
app_identifier: "com.example.app",
dev_portal_team_id: "TEAM_ID_NUMBER_DEV",
team_id: "ITS_TEAM_ID")
endA fenti példában a paramétereknek csak egy részét kell megadnunk: ezek a build paraméterek - séma, konfiguráció, Provision Profile nevek, valamint terjesztési paraméterek - a fejlesztői fiók Apple ID-je, jelszó, alkalmazásazonosító stb. tovább. Első közelítésként ezeket a kulcsokat speciális fájlokban helyeztük el - Gymfile, Matchfile и Appfile.
Mostantól a Jenkinsben olyan rövid parancsokat hívhat meg, amelyek nem homályosítják el a nézetet, és szemmel könnyen olvashatók:
# fastlane ios <lane_name>
$ fastlane ios build
$ fastlane ios test
$ fastlane ios run_sonar
$ fastlane ios deployHurrá, szuperek vagyunk
Mit kaptál? Tiszta parancsok minden lépéshez. Megtisztított szkriptek, szépen elrendezve a fastlane fájlokban. Örvendve rohantunk a fejlesztőkhöz, és megkértük őket, hogy adjanak hozzá mindent, amire szükségük van.
De időben rájöttünk, hogy ugyanazokkal a nehézségekkel fogunk találkozni - még mindig lesz 20 összeállítási szkriptünk, amelyek így vagy úgy elkezdik élni a saját életüket, nehezebb lesz szerkeszteni őket, mivel a forgatókönyvek tárolókba kerülnek, és nem fértünk oda. És általában véve nem lehet így megoldani a fájdalmunkat.
2. feladat: szerezzen egyetlen Fastfile-t N alkalmazáshoz
Most úgy tűnik, hogy a probléma megoldása nem olyan nehéz - állítsa be a változókat, és menjünk. Igen, valójában így sikerült megoldani a problémát. De abban a pillanatban, amikor elrontottuk, nem rendelkeztünk sem magával a fastlane-el, sem a Ruby-val kapcsolatban, amiben a fastlane le van írva, sem hasznos példákkal a hálózaton – mindenki, aki akkor a fastlane-ről írt, egy példára korlátozódott egy alkalmazáshoz. egy fejlesztő.
A Fastlane képes kezelni a környezeti változókat, és ezt már kipróbáltuk a Keychain jelszó beállításával:
ENV['KEYCHAIN_PASSWORD']A szkriptjeink megtekintése után azonosítottuk a közös részeket:
#for build, test and deploy
APPLICATION_SCHEME_NAME=appScheme
APPLICATION_PROJECT_NAME=app.xcodeproj
APPLICATION_WORKSPACE_NAME=app.xcworkspace
APPLICATION_NAME=appName
OUTPUT_IPA_NAME=appName.ipa
#app info
APP_BUNDLE_IDENTIFIER=com.example.appName
[email protected]
TEAM_ID=ABCD1234
FASTLANE_ITC_TEAM_ID=123456789Most, hogy elkezdjük használni ezeket a kulcsokat a fastlane fájlokban, ki kellett találnunk, hogyan juttatjuk el őket oda. A Fastlane erre kínál megoldást: . A dokumentáció azt mondja, hogy ha fontos, hogy kulcsokat töltsön be különböző célokra, hozzon létre több konfigurációs fájlt a fastlane könyvtárban .env, .env.default, .env.development.
Aztán úgy döntöttünk, hogy ezt a könyvtárat egy kicsit másképp használjuk. A fejlesztői tárba ne a fastlane szkripteket és azok metainformációit helyezzük el, hanem az alkalmazás egyedi kulcsait a fájlban .env.appName.
maguk Fastfile, Appfile, Matchfile и Gymfile, egy külön tárolóba rejtettük el. Egy további fájl más szolgáltatásokból származó jelszókulcsokkal volt elrejtve - .env.
Láthat egy példát .
A CI-n a hívás nem sokat változott; hozzáadtak egy konfigurációs kulcsot egy adott alkalmazáshoz:
# fastlane ios <lane_name> --env appName
$ fastlane ios build --env appName
$ fastlane ios test --env appName
$ fastlane ios run_sonar --env appName
$ fastlane ios deploy --env appNameA parancsok futtatása előtt betöltjük a tárolónkat szkriptekkel. Nem néz ki olyan jól:
git clone [email protected]/FastlaneCICD.git fastlane_temp
cp ./fastlane_temp/fastlane/* ./fastlane/
cp ./fastlane_temp/fastlane/.env fastlane/.envEgyelőre elhagyta ezt a megoldást, bár a Fastlane-nek van megoldása a Fastfile letöltésére import_from_git, de csak Fastfile esetén működik, más fájloknál nem. Ha „igazán szépet” akarsz, írd meg a sajátodat action.
Hasonló készlet készült az Android alkalmazásokhoz és a ReactNative-hoz, a fájlok ugyanabban a tárolóban vannak, de különböző ágakban iOS, android и react_native.
Amikor a kiadási csapat új lépést szeretne hozzáadni, a szkriptben bekövetkezett változásokat MR-en keresztül rögzítik a git-ben, többé nem kell keresni a hibás szkriptek vétkeseit, és általában most meg kell próbálni feltörni.
Most már biztos ennyi
Korábban időt töltöttünk az összes szkript karbantartásával, frissítésével és a frissítések következményeinek kijavításával. Nagyon kiábrándító volt, amikor a kiadások hibáinak és leállásainak okai egyszerű elírások voltak, amelyeket olyan nehéz volt nyomon követni a shell szkriptek zagyvaságában. Most az ilyen hibák a minimumra csökkentek. A változtatások egyszerre kerülnek bevezetésre az összes alkalmazásban. És 15 percet vesz igénybe egy új alkalmazás folyamatba helyezése – állítson be egy sablonfolyamatot a CI-n, és adja hozzá a kulcsokat a fejlesztő tárházához.
Úgy tűnik, hogy a Fastfile for Android és az alkalmazás aláírása továbbra is megmagyarázhatatlan, ha érdekes a cikk, írok egy folytatást. Örömmel látom kérdéseit vagy javaslatait „hogyan oldaná meg ezt a problémát” a megjegyzésekben vagy a Telegramon .
Forrás: will.com