En développant un projet pour la plateforme Android, même le plus petit, il est inévitable de faire face à un environnement de développement. En plus de l'Android SDK, il est nécessaire d'avoir la dernière version de Kotlin, Gradle, platform-tools et build-tools. Et si sur la machine du développeur, toutes ces dépendances sont généralement gérées grâce à l'IDE Android Studio, sur le serveur CI/CD, chaque mise à jour peut rapidement devenir un casse-tête. Et si dans le développement web, la solution à ce problème d'environnement est devenue le standard Docker, pourquoi ne pas essayer de résoudre un problème similaire en développement Android grâce à lui…
Pour ceux qui ne savent pas ce qu'est Docker — pour faire simple, c'est un outil qui crée des soi-disant « conteneurs » où se trouve un noyau d'OS minimal et un ensemble de logiciels nécessaires, que nous pouvons déployer où bon nous semble, tout en conservant l'environnement. Ce qui sera dans notre conteneur est défini dans le Dockerfile, qui est ensuite assemblé en une image exécutable partout et possédant des propriétés d'idempotence.
Le processus d'installation et les bases de Docker sont bien décrits sur son . Donc, en avançant un peu, voici le Dockerfile que nous avons obtenu
# Т.к. основным инструментом для сборки 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"
Nous le sauvegardons dans le dossier de notre projet Android et lançons la construction du conteneur avec la commande
docker build -t android-build:5.4-28-27 .Paramètre -t spécifie le tag ou le nom de notre conteneur, qui est généralement composé de son nom et de sa version. Dans notre cas, nous l'avons appelé android-build et pour la version, nous avons indiqué la combinaison des versions gradle, android-sdk et platform-tools. Plus tard, il nous sera plus facile de rechercher l'image souhaitée par nom en utilisant cette « version ».
Après que la construction soit terminée, nous pouvons utiliser notre image localement, nous pouvons la télécharger avec la commande docker push dans un dépôt public ou privé d'images pour pouvoir la télécharger sur d'autres machines.
À titre d'exemple, construisons le projet localement. Pour cela, dans le dossier du projet, exécutons la commande
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebugAnalysons ce qu'elle signifie :
docker run — la commande pour lancer l'image
-rm — signifie qu'après l'arrêt du conteneur, il supprime tout ce qui a été créé pendant sa vie
-v « $PWD »:/home/gradle/ — monte le dossier courant de notre projet Android dans le dossier interne du conteneur /home/gradle/
-w /home/gradle — définit le répertoire de travail du conteneur
android-build:5.4.1-28-27 — le nom de notre conteneur que nous avons construit
gradle assembleDebug — l'équipe de construction qui assemble notre projet
Si tout se passe bien, dans quelques secondes/minutes, vous verrez quelque chose comme ça sur votre écran BUILD SUCCESSFUL en 8m 3s! Et dans le dossier app/build/output/apk se trouvera l'application assemblée.
De la même manière, vous pouvez réaliser d'autres tâches Gradle — vérifier le projet, exécuter des tests, etc. L'avantage principal est que, si nous devons assembler le projet sur n'importe quelle autre machine, nous n'avons pas besoin de nous soucier de l'installation de tout l'environnement, il suffira de télécharger l'image nécessaire et de lancer l'assemblage.
Le conteneur ne conserve aucun changement, et chaque assemblage démarre de zéro, ce qui garantit d'une part l'identité de l'assemblage, peu importe où il est exécuté, d'autre part cela implique que nous devons télécharger toutes les dépendances et compiler tout le code à chaque fois, ce qui peut parfois prendre un temps considérable. Par conséquent, en plus du lancement "froid" habituel, nous avons une option pour démarrer l'assemblage en préservant ce qu'on appelle le "cache", où nous sauvegardons le dossier ~/.gradle simplement en le copiant dans le dossier de travail du projet, et au début de l'assemblage suivant, nous le remettons en place. Nous avons placé toutes les procédures de copie dans des scripts distincts et la commande de lancement est devenue ainsi
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"En conséquence, le temps moyen d'assemblage de notre projet a été réduit de plusieurs fois (selon le nombre de dépendances dans le projet, mais un projet moyen s'assemble ainsi en 1 minute au lieu de 5 minutes).
Tout cela n'a de sens que si vous avez votre propre serveur CI/CD interne, pour lequel vous vous occupez vous-même. Mais il existe maintenant de nombreux services cloud où tous ces problèmes sont résolus et vous n'avez pas à vous en soucier, et les propriétés nécessaires à l'assemblage peuvent également être spécifiées dans les paramètres du projet.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Avez-vous un système CI/CD interne ou utilisez-vous un service externe ?
Nous utilisons un serveur interne
Nous utilisons un service externe
Nous n'utilisons pas de CI/CD
Autre
42 utilisateurs ont voté. 16 utilisateurs se sont abstenus.
Source : habr.com
