ジェンキンスを作る方法はあなたの人生を楽にし、幸せになる

会社のモバイルアプリケーションの開発が産業基盤に切り替わると、自動アセンブリの問題が必ず浮上します。 継続的インテグレーションは、プロセスの不可欠な部分です。 このプロセスの結果は、顧客およびリモートテスターへのOTA配信のために、会社のデバイスでテストするためのアセンブリです。

会社のアカウントまたは顧客のアカウントで公開する場合、多数のプロファイルと証明書、キー、プロパティ、設定を処理する必要があります。 デバイスの特定のキーを交換することは必ずしも便利ではありません。 そのため、当社では、このプロセスを自動化するソリューションを考え出しました。 この記事では、アセンブリに使用されるすべてのデバイスでのアーティファクトの配布の自動化について説明します。

したがって、この記事では、継続的インテグレーションの一部として、iOSアセンブリとプロパティの証明書とプロファイルのコピー、およびすべてのJenkinsスレーブのAndroidアセンブリのキーのコピーを実装する方法について説明します。 そのような自動化は時間を節約し、間違いを避けるのに役立ちます。 この記事は、モバイルアプリケーションの開発者とJenkinsを管理する人々にとって興味深いものです。

行こう！

問題

数年前、Jenkins（継続的統合サーバー）を最初にセットアップしたとき、すべてのアセンブリが実行されるマシン（mak-mini）が1台しかありませんでした。 やがて、ジェンキンスは仮想マシンに移行し、ミニカーはスレーブ（プロジェクトの構築に使用されるジェンキンスの補助ノード）に変わりました。 iOSプロジェクトはMac OSおよびAndroidでのみビルドできるため、iOSプロジェクトはスレーブでビルドされ、Androidプロジェクトはマスター（Jenkins自身がインストールされている）でビルドされました。 プロジェクトをビルドするために必要なものはすべて手作業で2台のマシンにインストールおよびレイアウトされ、すべてが大丈夫でした！ 以前の記事の1つで「Jenkinsを使用してXcodeの異なるバージョンでiOSアプリケーションを自動的に構築する」でJenkinsを構成する方法について説明しました。

プロジェクトの数が増え、最初に1つのコレクターをiOSおよびAndroidプロジェクトに接続し、その後さらに接続しました。 接続されたばかりのスレーブでアプリケーションを構築するには、インストールされたツール、SDK、およびプロジェクトごとに、アプリケーションが署名するキーとファイルが必要です。

Jenkinsスレーブの設定を最適化すること、つまり、iOSおよびAndroidアプリケーションの署名に必要なファイルを自動的にコピーしてインストールすることにしました。

iOSから始めましょう

iOSプロジェクトを構築するためのJenkinsスレーブがいくつかあります。 すべてのスレーブにはラベルが付いているため、インストールされているXcodeのバージョンを確認できます。 負荷を分散するために、すべてのアセンブリにはラベルが付けられており、対応するXcodeを備えた任意のスレーブで実行できます。
iOSアプリケーションを構築するには、次のものが必要です。

• Xcode
• 開発者/配布証明書+秘密キー
• プロビジョニングプロファイル

通常、ジェンキンでは、配布アセンブリ（AdHoc、Enterprise、AppStore）を収集します。 しかし、私たちはそれぞれ多数の開発者アカウント用に収集する必要があり、キー付きの証明書がたくさんあります。
キー付きの証明書をリモートマシンに配置するには、次のものが必要です。

1. 証明書がインストールされているマシン上のキーを使用して証明書をエクスポートする
2. .p12ファイルをリモートマシンにコピーする
3. リモートマシンに移動して.p12ファイルを開き、パスワードを入力して証明書とキーをキーチェーンにインストールし、
4. 証明書とキーをインストールした後、キー情報を開き、「アクセス制御」タブで「すべてのアプリケーションにこのアイテムへのアクセスを許可する」を選択します

sshを介して同じことを行うには、securityコマンドを使用する必要があります。

プロファイルをインストールするには、目的のディレクトリにコピーするだけです：〜/ Library / MobileDevice / Provisioning \ Profiles /
この場合、古いプロファイルを削除することが望ましい。 Xcodeをビルドするとき、更新されたプロファイルの代わりに古いプロファイルを使用できます。

通常、プロファイルのリストを更新するには、Xcode設定に移動し、必要なアカウントを選択した後、[再読み込み]ボタンをクリックします。 Xcode自体は、ポータルで編集されている場合、古いプロファイルを新しいプロファイルに置き換えます。 しかし、すべてのアカウントの複数のマシンでこれを行うのは効果的ではなく、一般的に憂鬱です。

たとえば、rsyncを使用してフォルダー同期を構成し、1台のマシンでのみ手動でプロファイルを更新できます。 複数の人が証明書とプロファイルの編集と作成にアクセスでき、誰でも仮想マシンと自分のマシンの両方で作業できるため、少し異なるアプローチを選択しました：証明書、キー、プロファイルのgitリポジトリを作成しました。

その後、少し残っています-gitのスクリプトを更新するには、ファイルを実行します。これにより、Jenkinsノードによってファイルが分解され、証明書とキーがインストールされます。 私の最初の考えはgit-hookを書くことでしたが、gitマシンはJenkinsノードにアクセスできません。 しかし、ジェンキンスにはそれがあります。 そして、Jenkinsはgitへのプッシュが発生したときに開始するジョブの優れた仕事をしています-このために、webフックがgitのプロジェクトに追加されます。

その結果、次のことを行いました。

• プロファイルと証明書フォルダーに* .mobileprovisionおよび* .p12を含むgitリポジトリー
• gitからファイルを取得してスクリプトを実行するjenkinsのジョブ：
  
  

  #!/bin/bash slaves=( "192.168.2.10" "192.168.2.20" "192.168.2.30" ) for i in "${slaves[@]}" do ssh jenkins@"$i" rm -f "~/Library/MobileDevice/Provisioning\ Profiles/*" scp ${WORKSPACE}/profiles/* "jenkins@$i:/Users/jenkins/Library/MobileDevice/Provisioning\ Profiles/" ssh jenkins@"$i" mkdir -p "~/pp_cc" scp ${WORKSPACE}/certificates/* "jenkins@$i:/Users/jenkins/pp_cc/" ssh jenkins@"$i" 'security unlock-keychain -p jenkins /Users/jenkins/Library/Keychains/login.keychain; cd /Users/jenkins/pp_cc/; for a in *; do security import $a -k /Users/jenkins/Library/Keychains/login.keychain -P xxxXXXxxx -A; done' done 

  
  slavesはjenkinsスレーブの配列、またはむしろそれらのIPアドレスです。 xxxXXXxxx -p12からのパスワード。 はい、gitに入れるすべての証明書に同じパスワードを使用します。
  

Androidでも同じ魔法

Androidプロジェクトでは、状況は一般的に似ています。 アセンブリに署名するために、プロファイルと証明書の代わりにキーストアファイルのみが使用されます。 キーストアファイルを使用するには、パスワードとエイリアスを知っている必要があります。 Androidアプリケーションをアセンブルするには、Gradleを使用し、gradle.properties設定ファイルで次の情報を指定します。

 releaseStoreFile=/home/jenkins/gradle_keys/customer/project_name.keystore releaseStorePassword=project_pass releaseKeyAlias=project_alias releaseKeyPassword=project_pass 

簡単な状況では、キーストアファイルをアセンブリマシンに配置して、プロジェクトの.propertiesにアップロードできます。 困難は、開発者とアセンブラが異なるオペレーティングシステムで作業するときに始まります。同じ方法ですべてのマシンにキーを配置することは困難です。 Androidビルド向けのソリューション：

• キーストアとプロパティのgitリポジトリ
• スクリプトを実行するジェンキンスビルド：
  
  

   # slaves cp -r keys keys_for_ubuntu cd keys_for_ubuntu PATHREPL='\/home\/jenkins\/gradle_keys' find . -name "*\.properties" | while read line; do sed -i -e 's/'PATH_TO_KEYS'/'"$PATHREPL"'/g' "$line"; done slaves=( "192.168.2.10" "192.168.2.20" "192.168.2.30" ) for i in "${slaves[@]}" do scp -r ./ jenkins@"$i":/home/jenkins/gradle_keys/ done #master cd ../keys PATHREPL='\/var\/lib\/jenkins\/gradle_keys' find . -name "*\.properties" | while read line; do sed -i -e 's/'PATH_TO_KEYS'/'"$PATHREPL"'/g' "$line"; done cp -r ./ /var/lib/jenkins/gradle_keys/ 

  
  

ファイルをスレーブに分解するアセンブリは、常にウィザードで実行されます。 ウィザードはすべてのコレクターにアクセスできます。 さまざまなオペレーティングシステムの正しいパスを示すために、ファイルは「PATH_TO_KEYS」プレースホルダーを使用してgitに入れられます。 この場合、ファイルは次のようになります。

 releaseStoreFile=PATH_TO_KEYS/customer/project_name.keystore releaseStorePassword=project_pass releaseKeyAlias=project_alias releaseKeyPassword=project_pass 

ファイル内の必要なパスは、sedコマンドを使用して実行時に置き換えられます。 リポジトリからダウンロードしたファイルを数回使用するには、パスを変更する前に、それらを別のフォルダーにコピーします。 この例では、スレーブ上のホームディレクトリは同じですが、ウィザードのホームディレクトリとは異なります。
リリースビルドのプロジェクト設定では、gradle.propertiesへのパスはプロジェクトディレクトリを基準に指定されているため、プロパティファイルは〜/ gradle_keysコレクターの共有ディレクトリから作業ディレクトリにコピーする必要があります。

 cp ~/gradle_keys/customer/project_name.properties ${WORKSPACE}/ 

さらに改善する方法

すべてのスレーブのアドレスを書き出さないようにするには、 Elastic + Axisプラグインを使用します。これにより、複数のノードで実行するようにアセンブリを構成できます。 iOSビルダーを構成するためのスクリプトは次のようになります。

 rm -f ~/Library/MobileDevice/Provisioning\ Profiles/* cp ${WORKSPACE}/profiles/* ~/Library/MobileDevice/Provisioning\ Profiles/ security unlock-keychain -p jenkins $HOME/Library/Keychains/login.keychain; cd ${WORKSPACE}/certificates/; for a in *; do security import $a -k $HOME/Library/Keychains/login.keychain -P xxxXXXxxx -A; done 

Androidビルダーを構成するためのスクリプトは次のようになります。

 cd keys KEYS_PATH="$HOME/gradle_keys" REPL_PATH=$(echo "$KEYS_PATH" | sed -e 's/[\/&]/\\&/g') find . -name "*\.properties" | while read line; do sed -i -e "s/PATH_TO_KEYS/$REPL_PATH/g" "$line"; done cp -r ./ $KEYS_PATH 

結論

彼らは、良い記事を書きたいなら、あなたの決定の長所と短所について結論を書く必要があると言っています。 強みにより、すべてがシンプルです：

• このソリューションは、アセンブリのファイルを変更および追加する際の時間を節約します
• このソリューションは、インフラストラクチャを拡張しながらスレーブを追加する時間を節約します
• このソリューションを使用すると、重要なファイルへのアクセスを制限できます（キーと証明書はプロジェクトリポジトリにありません）-以前はありませんでしたが、一部のユーザーは
• ジェンキンスは自分で「調整」するため、この決定はクールです

弱点：

• このソリューションは、1つのリポジトリがすべてのAndroidプロジェクトのキーに使用され、iOSでも同様に使用されるという事実のために設計されています。 したがって、それへのアクセスの設定は柔軟性がありません-人はすべてにアクセスできるか、何にもアクセスできません。 そのようなファイルへのアクセスに、その分野のチーフテクニカルスペシャリストがいなくても、たとえばプロジェクトマネージャーがいなければ、このソリューションは機能しません。
• このアプローチのセキュリティは、一般にJenkinsのリリースアセンブリのアイデアの実装のセキュリティに大きく依存しています。つまり、それらを使用する場合は、キーをどこかに保存し、それらへのパスを規定する必要があり、セキュリティは収集されたアプリケーションの配布方法から、Jenkinsタスク、Jenkinsとそのビルダーがインストールされているマシンへのアクセスの設定。

おわりに

提案されたアプローチにより、当社は、アプリケーションの構築に必要な多数のアーティファクトの管理プロセスを簡素化できました。 現在、キーの変更と追加は高速で安定しており、必要なすべてのマシンで実行できます。 プロジェクト数の増加によるインフラストラクチャの拡大により、Jenkinsに新しいノードを追加するのも同じくらい迅速かつ簡単になりました。 経験を共有できることをうれしく思います。この記事が、開発およびサポートされた多数のアプリケーションが蓄積されている企業で同様の問題を解決するのに役立つことを嬉しく思います。