Mi ŝatus paroli pri kontinua integriĝo kaj livero por poŝtelefonaj programoj uzante fastlane. Kiel ni efektivigas CI/KD en ĉiuj moveblaj aplikoj, kiel ni alvenis tien kaj kio okazis finfine.
Jam estas sufiĉe da materialo en la reto pri la ilo, kiu tiom mankis al ni komence, do mi intence ne priskribos la ilon detale, sed nur referencos al tio, kion ni havis tiam:
La artikolo konsistas el du partoj:
- Fono al la apero de movebla CI/KD en la firmao
- Teknika solvo por disvolvado de CI/KD por N-aplikoj
La unua parto estas pli da nostalgio por la malnovaj tagoj, kaj la dua estas sperto, kiun vi povas apliki al vi mem.
Tiel okazis historie
Jaro 2015
Ni ĵus komencis evoluigi moveblajn aplikaĵojn, tiam ni sciis nenion pri kontinua integriĝo, pri DevOps kaj aliaj modaj aferoj. Ĉiu aplikaĵo ĝisdatigo estis lanĉita de la programisto mem de sia maŝino. Kaj se por Android ĝi estas sufiĉe simpla - kunmetita, subskribita .apk kaj alŝutis ĝin al la Google Developer Console, poste por iOS la tiama distribuilo per Xcode lasis al ni bonegajn vesperojn - provoj elŝuti la arkivon ofte finiĝis per eraroj kaj ni devis denove provi. Montriĝis, ke la plej altnivela programisto ne skribas kodon plurfoje monate, sed prefere liberigas la aplikaĵon.
Jaro 2016
Ni kreskis, ni jam pensis pri kiel liberigi programistojn de tuta tago por eldono, kaj aperis ankaŭ dua aplikaĵo, kiu nur puŝis nin pli al aŭtomatigo. Tiun saman jaron, ni instalis Jenkins por la unua fojo kaj skribis amason da timigaj skriptoj, tre similaj al tiuj, kiujn fastlane montras en sia dokumentaro.
$ 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"Bedaŭrinde, ĝis nun nur niaj programistoj sciis kiel ĉi tiuj skriptoj funkcias kaj kial ĉi tiu senfina stako de ŝlosiloj estas bezonata, kaj kiam io denove rompiĝis, ili ricevis la "belegajn vesperojn" por analizi protokolojn.
Jaro 2017
Ĉi-jare ni eksciis, ke ekzistas tia afero kiel fastlane. Ne estis tiom da informoj kiom nun — kiel komenci, kiel uzi ĝin. Kaj la ilo mem estis ankoraŭ kruda tiutempe: konstantaj eraroj nur seniluziigis nin kaj estis malfacile kredi je la magia aŭtomatigo, kiun ili promesis.
Tamen, la ĉefaj utilecoj inkluditaj en la rapidlena kerno estas gym и pilot, ni sukcesis komenci ĝin.
Niaj skriptoj estis iomete plibonigitaj.
$ fastlane gym —-workspace "Example.xcworkspace"
--scheme "AppName"
—-buildlog_path "/tmp"
-—cleanIli estis plibonigitaj, se nur ĉar ne ĉiuj parametroj necesaj por xcodebuild, vi devas indiki - gym sendepende komprenos kie kaj kio kuŝas. Kaj por pli da fajnagordado, vi povas specifi la samajn klavojn kiel en xcodebuild, nur la nomado de la klavoj estas pli klara.
Ĉi-foje, dank' al gimnazio kaj la enkonstruita xcpretty formatilo, la konstruprogramoj fariĝis multe pli legeblaj. Ĉi tio komencis ŝpari tempon pri riparado de rompitaj asembleoj, kaj foje la eldonteamo povis eltrovi ĝin memstare.
Bedaŭrinde, muntaj rapidmezuradoj xcodebuild и gym Ni ne faris ĝin, sed ni fidos la dokumentadon - ĝis 30% plirapidigo.
Ununura procezo por ĉiuj aplikoj
Jaro 2018 kaj nuna
Antaŭ 2018, la procezo de konstruado kaj disvolvado de aplikoj tute translokiĝis al Jenkins, programistoj ĉesis liberigi de siaj maŝinoj, kaj nur la eldona teamo havis la rajton liberigi.
Ni jam volis plibonigi la lanĉon de testoj kaj statika analizo, kaj niaj skriptoj kreskis kaj kreskis. Kreskis kaj ŝanĝiĝis kune kun niaj aplikoj. Tiutempe, estis proksimume 10 aplikoj. Konsiderante ke ni havas du platformojn, tio estas ĉirkaŭ 20 "vivantaj" skriptoj.
Ĉiufoje kiam ni volis aldoni novan paŝon al la skripto, ni devis kopii-alglui la pecojn en ĉiujn ŝelajn skriptojn. Eble ni povintus labori pli zorge, sed ofte tiaj ŝanĝoj finiĝis per tajperaroj, kiuj fariĝis vesperoj por ke la eldona teamo ripari skriptojn kaj ekscii, kiu inteligenta ulo aldonis ĉi tiun komandon kaj kion ĝi efektive faras. Ĝenerale, oni ne povas diri, ke la skriptoj por kunigo por unu platformo estis almenaŭ iom similaj. Kvankam ili certe faris la samon.
Por komenci procezon por nova aplikaĵo, necesis pasigi tagon por elekti "freŝan" version de ĉi tiuj skriptoj, sencimigi ĝin kaj diri ke "jes, ĝi funkcias."
En la somero de 2018, ni denove rigardis al la ankoraŭ evoluanta rapida vojo.
Tasko numero 1: resumu ĉiujn skriptopaŝojn kaj reverku ilin en Fastfile
Kiam ni komencis, niaj skriptoj aspektis kiel piedtuko konsistanta el ĉiuj ŝtupoj kaj lambastonoj en unu ŝelo-skripto en Jenkins. Ni ankoraŭ ne ŝanĝis al dukto kaj divido laŭ etapo.
Ni rigardis tion, kion ni havas kaj identigis 4 paŝojn, kiuj kongruas kun la priskribo de nia CI/KD:
- konstrui - instali dependecojn, kunmeti la arkivon,
- testo - ruli programtestojn, kalkulante kovradon,
- sonaro - lanĉas ĉiujn linterojn kaj sendas raportojn al SonarQube,
- deploji — sendante artefakton al alfa (TestFlight).
Kaj se vi ne eniras detalojn, preterlasante la ŝlosilojn uzatajn en agoj, vi ricevos ĉi tiun Fastdosiero:
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
endFakte, nia unua Fastfile montriĝis monstra, konsiderante kelkajn el la lambastonoj, kiujn ni ankoraŭ bezonis kaj la nombron da parametroj, kiujn ni anstataŭigis:
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")
endEn la supra ekzemplo, nur parto de la parametroj, kiujn ni devas specifi: ĉi tiuj estas la konstruaj parametroj - skemo, agordo, Provision Profile-nomoj, same kiel distribuaj parametroj - Apple-ID de la programisto-konto, pasvorto, aplika ID, ktp. on. Kiel unua aproksimado, ni metas ĉiujn ĉi tiujn ŝlosilojn en specialajn dosierojn - Gymfile, Matchfile и Appfile.
Nun en Jenkins vi povas voki mallongajn komandojn, kiuj ne malklarigas la vidon kaj estas facile legeblaj per la okulo:
# fastlane ios <lane_name>
$ fastlane ios build
$ fastlane ios test
$ fastlane ios run_sonar
$ fastlane ios deployHura, ni estas bonegaj
Kion vi ricevis? Klara komandoj por ĉiu paŝo. Purigitaj skriptoj, bonorde aranĝitaj en rapidaj dosieroj. Ĝojante, ni kuris al la programistoj petante ilin aldoni ĉion, kion ili bezonas al siaj deponejoj.
Sed ni konsciis ĝustatempe, ke ni renkontos la samajn malfacilaĵojn - ni ankoraŭ havus 20 kunvenajn skriptojn, kiuj iel aŭ alie komencus vivi sian propran vivon, estus pli malfacile redakti ilin, ĉar la skriptoj movus al deponejoj, kaj ni ne havis aliron tie. Kaj, ĝenerale, ne eblos solvi nian doloron tiel.
Tasko numero 2: akiru ununuran Fastfile por N aplikoj
Nun ŝajnas, ke solvi la problemon ne estas tiel malfacila - starigu la variablojn, kaj ni iru. Jes, fakte, tiel la problemo estis solvita. Sed en la momento, kiam ni fuŝis ĝin, ni havis nek kompetentecon pri fastlane mem, nek pri Ruby, en kiu fastlane estas skribita, nek utilajn ekzemplojn en la reto - ĉiuj, kiuj skribis pri fastlane tiam, estis limigitaj al ekzemplo por unu aplikaĵo. por unu programisto.
Fastlane povas pritrakti mediajn variablojn, kaj ni jam provis tion fiksante la Ŝlosilĉenpasvorton:
ENV['KEYCHAIN_PASSWORD']Post rigardado de niaj skriptoj, ni identigis la komunajn partojn:
#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=123456789Nun, por komenci uzi ĉi tiujn klavojn en rapidaj dosieroj, ni devis eltrovi kiel liveri ilin tie. Fastlane havas solvon por ĉi tio: . La dokumentaro diras, ke se gravas por vi ŝargi ŝlosilojn por malsamaj celoj, kreu plurajn agordajn dosierojn en la dosierujo fastlane. .env, .env.default, .env.development.
Kaj tiam ni decidis uzi ĉi tiun bibliotekon iomete alie. Ni metu en la deponejo de programistoj ne la fastlane-skriptojn kaj ĝiajn metainformojn, sed la unikajn ŝlosilojn de ĉi tiu aplikaĵo en la dosiero. .env.appName.
Ili mem Fastfile, Appfile, Matchfile и Gymfile, ni kaŝis ĝin en aparta deponejo. Plia dosiero kun pasvortŝlosiloj de aliaj servoj estis kaŝita tie - .env.
Vi povas vidi ekzemplon .
Ĉe CI, la voko ne multe ŝanĝiĝis; agorda ŝlosilo por specifa aplikaĵo estis aldonita:
# 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 appNameAntaŭ ol ruli la komandojn, ni ŝarĝas nian deponejon per skriptoj. Ne aspektas tiel bele:
git clone [email protected]/FastlaneCICD.git fastlane_temp
cp ./fastlane_temp/fastlane/* ./fastlane/
cp ./fastlane_temp/fastlane/.env fastlane/.envForlasis ĉi tiun solvon nuntempe, kvankam Fastlane havas solvon por elŝuti Fastfile per import_from_git, sed ĝi funkcias nur por Fastfile, sed ne por aliaj dosieroj. Se vi volas "vere bela", vi povas skribi vian propran action.
Simila aro estis farita por Android-aplikoj kaj ReactNative, la dosieroj estas en la sama deponejo, sed en malsamaj branĉoj iOS, android и react_native.
Kiam la eldona teamo volas aldoni novan paŝon, ŝanĝoj en la skripto estas registritaj per MR en git, ne plu necesas serĉi la kulpulojn de rompitaj skriptoj, kaj ĝenerale, nun vi devas provi rompi ĝin.
Nun tio estas certe
Antaŭe, ni pasigis tempon prizorgante ĉiujn skriptojn, ĝisdatigante ilin kaj riparante ĉiujn konsekvencojn de ĝisdatigoj. Estis tre seniluziigite kiam la kialoj de eraroj kaj malfunkcio en eldonoj estis simplaj tajperaroj, kiuj estis tiel malfacile konservi trako en la miksaĵo de ŝelaj skriptoj. Nun tiaj eraroj estas reduktitaj al minimumo. Ŝanĝoj estas lanĉitaj al ĉiuj aplikoj samtempe. Kaj necesas 15 minutoj por meti novan aplikaĵon en la procezon - starigu ŝablonon-dukton sur CI kaj aldonu la ŝlosilojn al la deponejo de la programisto.
Ŝajnas, ke la punkto kun Fastfile por Android kaj subskribo de aplikaĵo restas neklarigita; se la artikolo estas interesa, mi skribos daŭrigon. Mi ĝojos vidi viajn demandojn aŭ sugestojn "kiel vi solvus ĉi tiun problemon" en la komentoj aŭ en Telegramo .
fonto: www.habr.com