🥇Мобилно CICD изживяване: един стандарт за бърза лента за много мобилни приложения

Бих искал да говоря за непрекъсната интеграция и доставка за мобилни приложения, използващи fastlane. Как внедряваме CI/CD във всички мобилни приложения, как стигнахме до там и какво се случи в крайна сметка.

В мрежата вече има достатъчно материал за инструмента, който толкова ни липсваше в началото, така че умишлено няма да опиша инструмента подробно, а ще се позова само на това, което имахме тогава:

Статията се състои от две части:

Предистория на появата на мобилния CI/CD в компанията
Техническо решение за внедряване на CI/CD за N-приложения

Първата част е повече носталгия по старите времена, а втората е преживяване, което можете да приложите към себе си.

Така се е случило исторически

Година 2015

Току-що започнахме да разработваме мобилни приложения, тогава не знаехме нищо за непрекъснатата интеграция, за DevOps и други модерни неща. Всяка актуализация на приложението беше пусната от самия разработчик от неговата машина. И ако за Android е доста просто - сглобено, подписано .apk и го качи в Google Developer Console, след това за iOS тогавашният инструмент за разпространение чрез Xcode ни остави страхотни вечери - опитите за изтегляне на архива често завършваха с грешки и трябваше да опитаме отново. Оказа се, че най-напредналият разработчик не пише код няколко пъти в месеца, а по-скоро пуска приложението.

Година 2016

Пораснахме, вече имахме мисли как да освободим разработчиците от цял ден за издание и се появи и второ приложение, което само ни тласна повече към автоматизация. Същата година инсталирахме Jenkins за първи път и написахме куп страшни скриптове, много подобни на тези, които fastlane показва в своята документация.

$ 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"

За съжаление, досега само нашите разработчици знаеха как работят тези скриптове и защо е необходим този безкраен стек от ключове, и когато нещо се счупи отново, те получиха „прекрасните вечери“ за анализ на регистрационни файлове.

Година 2017

Тази година научихме, че има такова нещо като fastlane. Нямаше толкова много информация, колкото сега - как да стартирате такъв, как да го използвате. А самият инструмент беше все още груб по това време: постоянните грешки само ни разочароваха и беше трудно да повярваме в магическата автоматизация, която обещаваха.

Въпреки това, основните помощни програми, включени в ядрото на fastlane, са gym и pilot, успяхме да го стартираме.

Нашите скриптове са малко подобрени.

$ fastlane gym  —-workspace "Example.xcworkspace" 
                --scheme "AppName" 
                —-buildlog_path "/tmp" 
                -—clean

Те са подобрени, дори само защото не всички параметри, необходими за xcodebuild, трябва да посочите - gym самостоятелно ще разбере къде и какво се крие. А за по-фина настройка можете да посочите същите клавиши като в xcodebuild, само именуването на клавишите е по-ясно.

Този път, благодарение на gym и вградения xcpretty formatter, регистрационните файлове за изграждане са станали много по-четливи. Това започна да спестява време за поправяне на повредени модули и понякога екипът по пускането можеше да го разбере сам.

За съжаление, измервания на скоростта на сглобяване xcodebuild и gym Ние не го направихме, но ще се доверим на документацията - до 30% ускоряване.

Един процес за всички приложения

Година 2018 и сега

До 2018 г. процесът на изграждане и внедряване на приложения изцяло се премести в Jenkins, разработчиците спряха да пускат от своите машини и само екипът по пускането имаше право да пуска.

Вече искахме да подобрим стартирането на тестове и статичен анализ и нашите скриптове растяха и растяха. Нарасна и се промени заедно с нашите приложения. По това време приложенията бяха около 10. Имайки предвид, че имаме две платформи, това са около 20 „живи“ скрипта.

Всеки път, когато искахме да добавим нова стъпка към скрипта, трябваше да копираме и поставим парчетата във всички скриптове на обвивката. Може би бихме могли да работим по-внимателно, но често такива промени завършваха с правописни грешки, които се превръщаха в вечери за екипа по издаване, за да коригира скриптове и да разбере кой умник е добавил тази команда и какво всъщност прави. Като цяло не може да се каже, че скриптовете за сглобяване за една платформа са поне донякъде сходни. Въпреки че със сигурност са направили същото.

За да започне процес за ново приложение, беше необходимо да отделите един ден, за да изберете „прясна“ версия на тези скриптове, да я дебъгвате и да кажете, че „да, работи“.

През лятото на 2018 г. отново погледнахме към все още развиващия се фастлейн.

Задача №1: обобщете всички стъпки на скрипта и ги пренапишете в Fastfile

Когато започнахме, нашите скриптове изглеждаха като кърпа за крака, състояща се от всички стъпки и патерици в един shell скрипт в Jenkins. Все още не сме преминали към тръбопровод и разделяне по етапи.

Разгледахме какво имаме и идентифицирахме 4 стъпки, които отговарят на описанието на нашия CI/CD:

изграждане - инсталиране на зависимости, сглобяване на архива,
тестване - провеждане на тестове за разработчици, изчисляване на покритие,
сонар - стартира всички линтери и изпраща доклади до SonarQube,
разгръщане — изпращане на артефакт към алфа (TestFlight).

И ако не навлизате в подробности, пропускайки ключовете, използвани в действията, ще получите този Fastfile:

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
end

Всъщност първият ни Fastfile се оказа чудовищен, като се имат предвид някои от патериците, от които все още се нуждаехме, и броя на параметрите, които заместихме:

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")
end

В примера по-горе, само част от параметрите, които трябва да посочим: това са параметрите за изграждане - схема, конфигурация, имена на профили за предоставяне, както и параметри за разпространение - Apple ID на акаунта на програмист, парола, ID на приложението и т.н. На. Като първо приближение, поставяме всички тези ключове в специални файлове - Gymfile, Matchfile и Appfile.

Сега в Jenkins можете да извиквате кратки команди, които не замъгляват изгледа и са лесни за четене от окото:

# fastlane ios <lane_name>

$ fastlane ios build
$ fastlane ios test
$ fastlane ios run_sonar
$ fastlane ios deploy

Ура, страхотни сме

Какво получи? Ясни команди за всяка стъпка. Изчистени скриптове, спретнато подредени във файлове за бързо движение. Радвайки се, ние изтичахме до разработчиците с молба да добавят всичко необходимо към техните хранилища.

Но с времето разбрахме, че ще срещнем същите трудности - все още ще имаме 20 асемблиращи скрипта, които по един или друг начин ще започнат да живеят собствен живот, ще бъде по-трудно да ги редактираме, тъй като скриптовете ще се преместят в хранилища, и нямахме достъп до там. И като цяло няма да е възможно да решим болката си по този начин.

Задача #2: вземете един Fastfile за N приложения

Сега изглежда, че решаването на проблема не е толкова трудно - задайте променливите и да тръгваме. Да, всъщност така беше решен проблемът. Но в момента, в който го прецакахме, нямахме нито опит в самия fastlane, нито в Ruby, в който пише fastlane, нито полезни примери в мрежата - всички, които тогава писаха за fastlane, бяха ограничени до пример за едно приложение за един разработчик.

Fastlane може да обработва променливи на средата и ние вече опитахме това, като зададохме паролата на Keychain:

ENV['KEYCHAIN_PASSWORD']

След като разгледахме нашите скриптове, идентифицирахме общите части:

#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=123456789

Сега, за да започнем да използваме тези ключове във файловете на fastlane, трябваше да разберем как да ги доставим там. Fastlane има решение за това: зареждане на променливи чрез dotenv. В документацията се казва, че ако за вас е важно да зареждате ключове за различни цели, създайте няколко конфигурационни файла в директорията fastlane .env, .env.default, .env.development.

И тогава решихме да използваме тази библиотека малко по-различно. Нека поставим в хранилището на разработчиците не скриптовете за fastlane и неговата мета информация, а уникалните ключове на това приложение във файла .env.appName.

себе си Fastfile, Appfile, Matchfile и Gymfile, ние го скрихме в отделно хранилище. Там беше скрит допълнителен файл с ключове за парола от други услуги - .env.
Можете да видите пример тук.

При CI повикването не се е променило много; добавен е конфигурационен ключ за конкретно приложение:

# 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 appName

Преди да изпълним командите, зареждаме нашето хранилище със скриптове. Не изглежда толкова хубаво:

git clone [email protected]/FastlaneCICD.git fastlane_temp

cp ./fastlane_temp/fastlane/* ./fastlane/
cp ./fastlane_temp/fastlane/.env fastlane/.env

Оставих това решение за сега, въпреки че Fastlane има решение за изтегляне на Fastfile чрез действие import_from_git, но работи само за Fastfile, но не и за други файлове. Ако искате „наистина красиво“, можете да напишете свой собствен action.

Подобен набор е направен за Android приложения и ReactNative, файловете са в едно и също хранилище, но в различни клонове iOS, android и react_native.

Когато екипът за освобождаване иска да добави някаква нова стъпка, промените в скрипта се записват чрез MR в git, вече няма нужда да търсите виновниците за счупените скриптове и като цяло сега трябва да опитате да го разбиете.

Това е със сигурност

Преди прекарвахме време в поддържане на всички скриптове, актуализиране и коригиране на всички последствия от актуализациите. Беше много разочароващо, когато причините за грешките и прекъсванията в изданията бяха обикновени печатни грешки, които бяха толкова трудни за проследяване в бъркотията от скриптове на обвивката. Сега подобни грешки са сведени до минимум. Промените се разпространяват във всички приложения наведнъж. И отнема 15 минути, за да поставите ново приложение в процеса - настройте конвейер за шаблони в CI и добавете ключовете към хранилището на програмиста.

Изглежда, че въпросът с Fastfile за Android и подписа на приложението остава необяснен, ако статията е интересна, ще напиша продължение. Ще се радвам да видя вашите въпроси или предложения „как бихте решили този проблем“ в коментарите или в Telegram башкирова.

Източник: www.habr.com

Мобилно CICD изживяване: един стандарт за бърза лента за много мобилни приложения