モバイル CICD エクスペリエンス: 多くのモバイル アプリケーションに XNUMX つのファーストレーン標準を適用

fastlane を使用したモバイル アプリの継続的インテグレーションとデリバリーについてお話ししたいと思います。すべてのモバイル アプリケーションに CI/CD を実装する方法、そこに至るまでの経緯、そして最終的に何が起こったかについて説明します。

当初は不足していたツールに関する資料はすでにインターネット上にたくさんあるので、ここではあえてツールの詳細について説明せず、当時私たちが持っていたものについてのみ言及します。

• 公式ファストレーンドキュメント
• 他の企業の例
• FastlaneでiOSアプリのビルドを自動化

この記事は XNUMX つの部分で構成されています。

• 企業におけるモバイルCI/CDの登場の背景
• NアプリケーションへのCI/CDの展開のための技術ソリューション

最初の部分は昔への懐かしさを感じさせるもので、2 番目の部分は自分自身に適用できる体験です。

歴史的にはこうなった

年2015

私たちはモバイルアプリの開発を始めたばかりで、継続的インテグレーションやDevOps、その他の高度な技術については何も知りませんでした。アプリのアップデートはすべて開発者自身が自分のマシンから行っていました。 Android 非常にシンプルです。収集、署名 .apk そしてそれを Google Developer Console に投入し、iOS の場合は Xcode 経由の配布ツールで素晴らしい夜を過ごしました。アーカイブをダウンロードしようとするとエラーで終了することが多く、再試行する必要がありました。最も優れた開発者は月に数回コードを書くのではなく、アプリケーションのリリースに従事していることがわかりました。

年2016

私たちは成長し、リリースのために開発者を丸一日解放する方法についてすでに考えていましたが、2 番目のアプリケーションが登場し、自動化に向けてさらに前進しました。同じ年に、私たちは初めて 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 "appleId@example.com" 
-p "PASS_APPLE_ID"

残念ながら、これらのスクリプトがどのように機能し、この無限のキーパックの目的を知っていたのは私たちの開発者だけでした。そして、何かが再び壊れたとき、彼らはログを分析するための「贅沢な夜」を過ごしました。

年2017

今年、私たちはファストレーンというものがあることを知りました。始め方や使い方など、今ほど多くの情報がありませんでした。そして、当時のツール自体はまだ未熟で、頻繁にエラーが発生し、私たちはがっかりし、約束された魔法のような自動化を信じることができませんでした。

ただし、Fastlane コアに含まれる主なユーティリティは次のとおりです。 gym и pilot、なんとか始めることができました。

私たちのスクリプトは少し改良されました。

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

それらは、必要なすべてのパラメータが満たされていないという理由だけで、より洗練されてきた。 xcodebuild、指定する必要があります - gym どこに何があるのか​​を自力で理解します。さらに細かく調整するには、同じキーを指定します。 xcodebuildキーの名前付けだけが明確になります。

今回は、gym と組み込みの xcpretty フォーマッタのおかげで、ビルド ログがはるかに明確になりました。これにより、壊れたビルドを修正する時間が節約され、リリース チームが独自に問題を解決できる場合もありました。

残念ながら、組み立て速度の測定はありません。 xcodebuild и gym 私たちはそれを実行しませんでしたが、ドキュメントを信頼します - 最大 30% の加速。

すべてのアプリケーションを単一のプロセスで実行

2018年現在

2018 年までに、アプリケーションの構築と展開のプロセスは完全に Jenkins に移行し、開発者は自分のマシンからのリリースを停止し、リリース チームのみがリリース権限を持つようになりました。

私たちはすでにテストと静的分析の起動を微調整したいと考えており、スクリプトはどんどん大きくなっていきました。私たちのアプリケーションとともに成長し、変化しました。その時の応募は10件くらいでした。プラットフォームが 20 つあることを考えると、約 XNUMX 個の「ライブ」スクリプトになります。

スクリプトに新しいステップを追加するたびに、すべてのシェル スクリプトに部分をコピーして貼り付ける必要がありました。おそらくもっと注意深く作業することも可能だったのでしょうが、そうした変更はしばしばタイプミスに終わり、リリース チームが何夜もかけてスクリプトを修正し、誰がこのコマンドを追加したのか、またそのコマンドが何をするのかを調べることになりました。一般に、1 つのプラットフォームのアセンブリのスクリプトが何らかの点で類似しているとは言えません。確かに彼らは同じことをしたのです。

新しいアプリケーションのプロセスを開始するには、これらのスクリプトから「新しい」バージョンを選択し、デバッグして「はい、動作します」と言うのに 1 日を費やす必要がありました。

2018 年の夏、私たちはまだ発展途上のファストレーンを改めて見直しました。

タスク1: すべてのスクリプトステップを要約し、Fastfileに書き直す

作業を開始した当初、スクリプトは Jenkins の 1 つのシェル スクリプトにすべてのステップとハックが詰め込まれた混乱したもののように見えました。まだパイプラインとステージごとの分割に切り替えていません。

私たちは現状を確認し、CI/CD の説明に適合する 4 つのステップを特定しました。

• ビルド - 依存関係をインストールし、アーカイブをビルドし、
• テスト - 開発者ユニットテストの実行、カバレッジの計算、
• sonar — すべてのリンターを起動し、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: "appleId@example.com",
  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

やったー、順調だよ！

何をもらいましたか？すべてのステップの明確なコマンド。きちんとしたスクリプトが、Fastlane ファイルにきちんとレイアウトされています。私たちは大喜びして、必要なものをすべてリポジトリに追加するよう開発者に依頼しました。

しかし、やがて私たちは同じ困難に直面するだろうと認識しました。つまり、依然として 20 個のビルド スクリプトがそれぞれ独自の動作を開始し、スクリプトがリポジトリに移動されてアクセスできなくなるため、編集がさらに困難になるということです。そして、一般的に、この方法で私たちの苦痛を解決することは不可能でしょう。

タスク #2: N 個のアプリケーションに対して単一の Fastfile を取得する

今では、問題を解決するのはそれほど難しくないようです。変数を設定して、始めましょう。はい、実際私たちはそのようにして問題を解決しました。しかし、これを実装していた当時は、fastlane 自体の専門知識も、fastlane が記述されている Ruby の専門知識も、Web 上の有用な例もありませんでした。当時 fastlane について書いた人は皆、1 人の開発者向けの 1 つのアプリケーションの例に限定していました。

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
APPLE_ID=appleID@example.com
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 git@repository.com/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.

リリース チームが新しいステップを追加したい場合、スクリプトの変更は git の MR を介して記録されるため、壊れたスクリプトの原因を探す必要がなくなり、一般的に、今すぐにそれを壊すには、試してみる必要があります。

これで全ては確実だ

以前は、すべてのスクリプトの保守、更新、および更新によるすべての結果の修正に時間を費やしていました。エラーやリリースのダウンタイムの原因が、シェル スクリプトの混乱の中で追跡するのが非常に困難な単純なタイプミスであったときは、非常にイライラしました。現在では、そのようなエラーは最小限に抑えられています。変更はすべてのアプリケーションに一度に展開されます。また、プロセスに新しいアプリケーションを追加するには、CI でテンプレート パイプラインを設定し、開発者リポジトリにキーを追加するだけで 15 分かかります。

Fastfileに関するポイントは未だに説明されていないようです。 Android そして、アプリケーションの署名についても触れています。この記事が好評であれば、続編を執筆します。この問題の解決策について、ご質問やご提案がありましたら、コメント欄またはTelegramにてお寄せください。 バシキロワ.

出所： habr.com