Android プラットフォーム用のプロジェクトを開発する場合、それがたとえどんなに小さなものであっても、遅かれ早かれ開発環境に対処する必要があります。 Android SDK に加えて、Kotlin、Gradle、プラットフォーム ツール、ビルド ツールの最新バージョンが必要です。 そして、開発者のマシン上で Android Studio IDE を使用してこれらすべての依存関係が大幅に解決される場合、CI / CD サーバー上では、各更新が頭痛の種になる可能性があります。 Web 開発において Docker が環境問題に対する標準的な解決策になっているのであれば、Android 開発でも Docker を使用して同様の問題を解決してみてはいかがでしょうか...
Docker が何であるかを知らない人のために説明します。非常に単純であれば、これはいわゆる Docker を作成するためのツールです。 最小限のOSカーネルと必要なソフトウェア一式を収めた「コンテナ」で、環境を維持しながら好きな場所にデプロイできます。 コンテナーに正確に何が含まれるかは Dockerfile で決定され、その後、どこでも起動でき、冪等性のプロパティを持つイメージに組み立てられます。
インストールプロセスと Docker の基本は、彼のドキュメントに美しく説明されています。 。 したがって、少し先を見据えると、このような Dockerfile があります
# Т.к. основным инструментом для сборки Android-проектов является Gradle,
# и по счастливому стечению обстоятельств есть официальный Docker-образ
# мы решили за основу взять именно его с нужной нам версией Gradle
FROM gradle:5.4.1-jdk8
# Задаем переменные с локальной папкой для Android SDK и
# версиями платформы и инструментария
ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip"
ANDROID_HOME="/usr/local/android-sdk"
ANDROID_VERSION=28
ANDROID_BUILD_TOOLS_VERSION=28.0.3
# Создаем папку, скачиваем туда SDK и распаковываем архив,
# который после сборки удаляем
RUN mkdir "$ANDROID_HOME" .android
&& cd "$ANDROID_HOME"
&& curl -o sdk.zip $SDK_URL
&& unzip sdk.zip
&& rm sdk.zip
# В следующих строчках мы создаем папку и текстовые файлы
# с лицензиями. На оф. сайте Android написано что мы
# можем копировать эти файлы с машин где вручную эти
# лицензии подтвердили и что автоматически
# их сгенерировать нельзя
&& mkdir "$ANDROID_HOME/licenses" || true
&& echo "24333f8a63b6825ea9c5514f83c2829b004d1" > "$ANDROID_HOME/licenses/android-sdk-license"
&& echo "84831b9409646a918e30573bab4c9c91346d8" > "$ANDROID_HOME/licenses/android-sdk-preview-license"
# Запускаем обновление SDK и установку build-tools, platform-tools
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}"
"platforms;android-${ANDROID_VERSION}"
"platform-tools"
これを Android プロジェクトのあるフォルダーに保存し、次のコマンドでコンテナーの構築を開始します。
docker build -t android-build:5.4-28-27 .パラメーター -t コンテナのタグまたは名前を設定します。通常、コンテナの名前とバージョンで構成されます。 私たちの場合、これを android-build と呼び、バージョンでは gradle、android-sdk、platform-tools のバージョンの組み合わせを指定しました。 将来的には、このような「バージョン」を使用して、必要な画像を名前で検索することが容易になるでしょう。
ビルドが完了したら、イメージをローカルで使用できるようになり、次のコマンドでダウンロードできます。 Dockerプッシュ 他のマシンにダウンロードするために、パブリックまたはプライベートのイメージ リポジトリにコピーします。
例として、ローカル プロジェクトを構築してみましょう。 これを行うには、プロジェクト フォルダーで次のコマンドを実行します。
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebugそれが何を意味するのか見てみましょう:
ドッカーラン - イメージ起動コマンド自体
-rm - コンテナを停止した後、コンテナの存続期間中に作成されたすべてのものが削除されることを意味します
-v "$PWD":/home/gradle/ - Android プロジェクトを含む現在のフォルダーをコンテナーの内部フォルダー /home/gradle/ にマウントします。
-w /ホーム/グラドル - コンテナの作業ディレクトリを設定します
アンドロイドビルド:5.4.1-28-27 - 収集したコンテナの名前
gradle アセンブルデバッグ - プロジェクトを組み立てるビルドチーム自体
すべてがうまくいけば、数秒または数分後に次のようなメッセージが表示されます。 8分3秒でビルド成功！ app/build/output/apk フォルダーには、組み立てられたアプリケーションが存在します。
同様に、プロジェクトのチェック、テストの実行など、他の Gradle タスクを実行できます。 主な利点は、プロジェクトを他のマシンにビルドする必要がある場合、環境全体のインストールについて心配する必要がなく、必要なイメージをダウンロードしてその中でビルドを実行するだけで十分であることです。
コンテナーには変更は保存されず、各アセンブリは最初から起動されます。これにより、どこで起動されるかに関係なくアセンブリの ID が保証される一方で、すべての依存関係をダウンロードする必要があるたびに、すべてのコードを再度コンパイルしますが、これにはかなりの時間がかかる場合があります。 したがって、通常の「コールド」スタートに加えて、いわゆる「コールド」スタートを維持しながらアセンブリを開始するオプションもあります。 「キャッシュ」。~/.gradle フォルダーをプロジェクトの作業フォルダーにコピーするだけで保存し、次のビルドの開始時にそれを返します。 すべてのコピー手順を別のスクリプトに移動し、起動コマンド自体は次のようになりました。
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 /bin/bash -c "./pre.sh; gradle assembleDebug; ./post.sh"その結果、プロジェクトの平均ビルド時間は数分の 1 に短縮されました (プロジェクトの依存関係の数によって異なりますが、平均的なプロジェクトは 5 分ではなく XNUMX 分でビルドされるようになりました)。
これらすべては、あなた自身がサポートする独自の内部 CI / CD サーバーを持っている場合にのみ意味を成します。 しかし、現在ではこれらの問題がすべて解決されている多くのクラウド サービスがあり、心配する必要はありません。必要なビルド プロパティもプロジェクト設定で指定できます。
登録ユーザーのみがアンケートに参加できます。 お願いします。
CI/CD システムを社内に保持しますか、それともサードパーティのサービスを使用しますか?
-
内部サーバーの使用
-
外部サービスを利用する
-
CI/CDは使用しません
-
その他
42 人のユーザーが投票しました。 16名のユーザーが棄権した。
出所： habr.com