Haluaisin puhua mobiilisovellusten jatkuvasta integroinnista ja toimittamisesta fastlanen avulla. Kuinka toteutamme CI/CD:n kaikissa mobiilisovelluksissa, miten pääsimme perille ja mitä lopulta tapahtui.
Verkossa on jo tarpeeksi materiaalia työkalusta, jota meiltä niin puuttui alussa, joten en tarkoituksella kuvaile työkalua yksityiskohtaisesti, vaan viittaan vain siihen, mitä meillä oli silloin:
Artikkeli koostuu kahdesta osasta:
- Taustaa mobiilin CI/CD:n syntymiselle yrityksessä
- Tekninen ratkaisu CI/CD:n käyttöönottoon N-sovelluksille
Ensimmäinen osa on enemmän nostalgiaa vanhaan aikaan, ja toinen on kokemus, jota voit soveltaa itseesi.
Näin se tapahtui historiallisesti
Vuosi 2015
Aloitimme juuri mobiilisovellusten kehittämisen, mutta emme tienneet mitään jatkuvasta integroinnista, DevOpsista ja muista muodikkaista asioista. Kehittäjä itse julkaisi jokaisen sovelluspäivityksen koneeltaan. Ja jos se on Androidille melko yksinkertaista - koottu, allekirjoitettu .apk ja latasin sen Google Developer Consoleen, sitten iOS:lle tuolloinen Xcoden kautta levitetty työkalu jätti meille hienot illat - arkiston latausyritykset päättyivät usein virheisiin ja meidän piti yrittää uudelleen. Kävi ilmi, että edistynein kehittäjä ei kirjoita koodia useita kertoja kuukaudessa, vaan julkaisee sovelluksen.
Vuosi 2016
Kasvoimme aikuisiksi, meillä oli jo ajatuksia kuinka vapauttaa kehittäjät koko päivältä julkaisua varten, ja myös toinen sovellus ilmestyi, mikä vain työnsi meidät enemmän kohti automaatiota. Samana vuonna asensimme Jenkinsin ensimmäistä kertaa ja kirjoitimme joukon pelottavia skriptejä, jotka ovat hyvin samanlaisia kuin ne, jotka fastlane näyttää dokumentaatiossaan.
$ 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"Valitettavasti tähän asti vain kehittäjämme tiesivät kuinka nämä skriptit toimivat ja miksi tätä loputonta avaimia tarvitaan, ja kun jokin taas meni rikki, he saivat "upeat illat" lokien analysointiin.
Vuosi 2017
Tänä vuonna opimme, että on olemassa sellainen asia kuin fastlane. Tietoa ei ollut niin paljon kuin nyt - kuinka aloittaa, miten sitä käytetään. Ja itse työkalu oli tuolloin vielä karkea: jatkuvat virheet pettyivät ja oli vaikea uskoa niiden lupaamaan maagiseen automaatioon.
Kuitenkin tärkeimmät apuohjelmat, jotka sisältyvät fastlane-ytimeen, ovat gym и pilot, onnistuimme käynnistämään sen.
Käsikirjoituksiamme on hieman parannettu.
$ fastlane gym —-workspace "Example.xcworkspace"
--scheme "AppName"
—-buildlog_path "/tmp"
-—cleanNiitä on parannettu, jos vain siksi, ettei kaikkia tarvittavia parametreja ole xcodebuild, sinun on ilmoitettava - gym ymmärtää itsenäisesti missä ja mikä on. Ja hienosäätöä varten voit määrittää samat näppäimet kuin sisään xcodebuild, vain näppäinten nimeäminen on selkeämpi.
Tällä kertaa kuntosalin ja sisäänrakennetun xcpretty-muotoilijan ansiosta rakennuslokit ovat tulleet paljon luettavammiksi. Tämä alkoi säästää aikaa rikkoutuneiden kokoonpanojen korjaamiseen, ja joskus julkaisutiimi pystyi keksimään sen itse.
Valitettavasti kokoonpanon nopeusmittaukset xcodebuild и gym Emme tehneet sitä, mutta luotamme dokumentaatioon – jopa 30 % nopeutta.
Yksi prosessi kaikille sovelluksille
Vuosi 2018 ja nykyhetki
Vuoteen 2018 mennessä sovellusten rakentamis- ja käyttöönottoprosessi siirtyi kokonaan Jenkinsiin, kehittäjät lopettivat julkaisun koneistaan, ja vain julkaisutiimillä oli oikeus julkaista.
Halusimme jo parantaa testien ja staattisen analyysin käynnistämistä, ja skriptimme kasvoivat ja kasvoivat. Kasvoimme ja muuttuivat sovelluksiemme myötä. Tuolloin sovelluksia oli noin 10. Ottaen huomioon, että meillä on kaksi alustaa, se on noin 20 "elävää" skriptiä.
Joka kerta kun halusimme lisätä skriptiin uuden vaiheen, meidän piti kopioida ja liittää kappaleet kaikkiin komentotulkkikomentosarjaan. Ehkä olisimme voineet työskennellä huolellisemmin, mutta usein tällaiset muutokset päättyivät kirjoitusvirheisiin, jotka muuttuivat julkaisutiimin illaksi korjata skriptejä ja selvittää, mikä fiksu lisäsi tämän komennon ja mitä se oikeastaan tekee. Yleisesti ottaen ei voida sanoa, että yhden alustan kokoonpanon skriptit olisivat vähintäänkin samanlaisia. Vaikka he tekivät varmasti saman asian.
Uuden sovelluksen prosessin aloittamiseksi piti viettää päivä valitakseen "tuore" versio näistä komentosarjoista, korjata se ja sanoa, että "kyllä, se toimii".
Kesällä 2018 katselimme jälleen yhä kehittyvää fastlanea kohti.
Tehtävä #1: tee yhteenveto kaikista komentosarjan vaiheista ja kirjoita ne uudelleen Fastfileen
Kun aloitimme, käsikirjoituksemme näyttivät jalkakankaalta, joka koostui kaikista portaista ja kainalosauvoista yhdessä kuoren käsikirjoituksessa Jenkinsissä. Emme ole vielä siirtyneet putkistoon ja vaiheittain jakoon.
Tarkastelimme mitä meillä on ja tunnistimme 4 vaihetta, jotka sopivat CI/CD:n kuvaukseen:
- rakentaa - riippuvuuksien asentaminen, arkiston kokoaminen,
- testi – kehittäjäyksikkötestien suorittaminen, kattavuuden laskeminen,
- kaikuluotain – käynnistää kaikki linterit ja lähettää raportteja SonarQubelle,
- käyttöönotto — artefaktin lähettäminen alfalle (TestFlight).
Ja jos et mene yksityiskohtiin jättäen pois toiminnassa käytetyt näppäimet, saat tämän Fast-tiedoston:
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
endItse asiassa ensimmäinen Fastfilemme osoittautui hirviömäiseksi, kun otetaan huomioon joitain vielä tarvitsemamme kainalosauvat ja korvaamiemme parametrien lukumäärä:
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")
endYllä olevassa esimerkissä vain osa parametreista, jotka meidän on määritettävä: nämä ovat koontiparametrit - skeema, kokoonpano, käyttöprofiilien nimet sekä jakeluparametrit - kehittäjätilin Apple ID, salasana, sovellustunnus ja niin edelleen. päällä. Ensimmäisenä arviona laitamme kaikki nämä avaimet erityisiin tiedostoihin - Gymfile, Matchfile и Appfile.
Nyt Jenkinsissä voit kutsua lyhyitä komentoja, jotka eivät sumenna näkymää ja ovat helposti luettavissa silmällä:
# fastlane ios <lane_name>
$ fastlane ios build
$ fastlane ios test
$ fastlane ios run_sonar
$ fastlane ios deployHurraa, olemme mahtavia
Mitä sinä sait? Selkeät komennot jokaisessa vaiheessa. Puhdistetut skriptit, siististi järjestetty fastlane-tiedostoihin. Iloitellen juoksimme kehittäjien luo ja pyysimme heitä lisäämään kaiken tarvitsemansa arkistoihinsa.
Mutta tajusimme ajoissa, että kohtaamme samat vaikeudet - meillä olisi vielä 20 kokoonpanoskriptiä, jotka tavalla tai toisella alkaisivat elää omaa elämäänsä, niitä olisi vaikeampi muokata, koska skriptit siirtyisivät arkistoihin, eikä meillä ollut pääsyä sinne. Ja yleensä, tuskaamme ei ole mahdollista ratkaista tällä tavalla.
Tehtävä #2: hanki yksi Fastfile N-sovellukselle
Nyt näyttää siltä, että ongelman ratkaiseminen ei ole niin vaikeaa - aseta muuttujat ja mennään. Kyllä, itse asiassa ongelma ratkesi näin. Mutta sillä hetkellä, kun sotimme sen, meillä ei ollut asiantuntemusta itse fastlanesta eikä Rubysta, johon fastlane on kirjoitettu, eikä hyödyllisiä esimerkkejä verkossa - kaikki, jotka kirjoittivat fastlanesta silloin, rajoittuivat esimerkkiin yhteen sovellukseen. yksi kehittäjä.
Fastlane pystyy käsittelemään ympäristömuuttujia, ja olemme jo kokeilleet tätä asettamalla avainnipun salasanan:
ENV['KEYCHAIN_PASSWORD']Katsottuamme skriptejämme tunnistimme yhteiset osat:
#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=123456789Nyt, jotta voimme alkaa käyttää näitä avaimia fastlane-tiedostoissa, meidän oli keksittävä, kuinka ne toimitetaan sinne. Fastlanella on tähän ratkaisu: . Dokumentaatio sanoo, että jos sinun on tärkeää ladata avaimia eri tarkoituksiin, luo useita asetustiedostoja fastlane-hakemistoon .env, .env.default, .env.development.
Ja sitten päätimme käyttää tätä kirjastoa hieman eri tavalla. Laitetaan kehittäjien arkistoon ei fastlane-skriptejä ja niiden metatietoja, vaan tämän sovelluksen ainutlaatuiset avaimet tiedostossa .env.appName.
itse Fastfile, Appfile, Matchfile и Gymfile, piilotimme sen erilliseen arkistoon. Siellä oli piilotettu ylimääräinen tiedosto, jossa oli muiden palveluiden salasanaavaimia - .env.
Voit nähdä esimerkin .
CI:ssä puhelu ei ole juurikaan muuttunut; konfigurointiavain tietylle sovellukselle on lisätty:
# 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 appNameEnnen komentojen suorittamista lataamme arkistomme komentosarjoilla. Ei näytä niin kivalta:
git clone [email protected]/FastlaneCICD.git fastlane_temp
cp ./fastlane_temp/fastlane/* ./fastlane/
cp ./fastlane_temp/fastlane/.env fastlane/.envJätin tämän ratkaisun toistaiseksi, vaikka Fastlanella on ratkaisu Fastfilen lataamiseen import_from_git, mutta se toimii vain Fastfilelle, mutta ei muille tiedostoille. Jos haluat "todella kaunista", voit kirjoittaa omasi action.
Samanlainen sarja tehtiin Android-sovelluksille ja ReactNativelle, tiedostot ovat samassa arkistossa, mutta eri haaroissa iOS, android и react_native.
Kun julkaisutiimi haluaa lisätä uuden askeleen, skriptin muutokset tallennetaan MR:n kautta gitissä, rikkinäisten skriptien syyllisiä ei enää tarvitse etsiä, ja yleensäkin nyt pitää yrittää rikkoa se.
Nyt se on varma
Aikaisemmin käytimme aikaa kaikkien komentosarjojen ylläpitoon, niiden päivittämiseen ja kaikkien päivitysten seurausten korjaamiseen. Oli suuri pettymys, kun julkaisujen virheiden ja seisokkien syyt olivat yksinkertaiset kirjoitusvirheet, joita oli niin vaikea seurata shell-skriptien sekamelskassa. Nyt tällaiset virheet on vähennetty minimiin. Muutokset otetaan käyttöön kaikkiin sovelluksiin kerralla. Ja uuden sovelluksen ottaminen prosessiin vie 15 minuuttia – luo malliputkisto CI:lle ja lisää avaimet kehittäjän arkistoon.
Vaikuttaa siltä, että Androidin Fastfilen ja sovelluksen allekirjoituksen pointti jää selittämättömäksi; jos artikkeli on mielenkiintoinen, kirjoitan jatkoa. Näen mielelläni kysymyksesi tai ehdotuksesi "miten ratkaisisit tämän ongelman" kommenteissa tai Telegramissa .
Lähde: will.com