ProHoster > Blog > administration > Construire un projet Android dans un conteneur Docker

Construire un projet Android dans un conteneur Docker

Lors du développement d'un projet pour la plate-forme Android, même le plus petit, vous devez tôt ou tard faire face à l'environnement de développement. En plus du SDK Android, il est nécessaire d'avoir la dernière version de Kotlin, Gradle, platform-tools, build-tools. Et si sur la machine du développeur toutes ces dépendances sont résolues dans une plus large mesure à l'aide de l'IDE Android Studio, alors sur le serveur CI / CD, chaque mise à jour peut se transformer en casse-tête. Et si dans le développement web, Docker est devenu la solution standard au problème d'environnement, alors pourquoi ne pas essayer de résoudre un problème similaire avec lui dans le développement Android...

Pour ceux qui ne savent pas ce qu'est Docker - si c'est assez simple, alors c'est un outil pour créer le soi-disant. "Conteneurs" qui contiennent le noyau OS minimum et l'ensemble de logiciels nécessaires que nous pouvons déployer où nous voulons, tout en préservant l'environnement. Ce qui se trouvera exactement dans notre conteneur est déterminé dans le Dockerfile, qui est ensuite assemblé en une image qui peut être lancée n'importe où et qui possède des propriétés d'idempotence.

Le processus d'installation et les bases de Docker sont magnifiquement décrits sur son le site officiel. Par conséquent, en regardant un peu plus loin, nous avons un tel 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"

Nous l'enregistrons dans le dossier avec notre projet Android et commençons à construire le conteneur avec la commande

docker build -t android-build:5.4-28-27 .

Paramètre -t définit la balise ou le nom de notre conteneur, qui se compose généralement de son nom et de sa version. Dans notre cas, nous l'avons appelé android-build et dans la version, nous avons spécifié une combinaison de versions gradle, android-sdk et platform-tools. À l'avenir, il nous sera plus facile de rechercher l'image dont nous avons besoin par son nom en utilisant une telle «version».

Une fois la construction terminée, nous pouvons utiliser notre image localement, nous pouvons la télécharger avec la commande docker poussée vers un référentiel d'images public ou privé afin de le télécharger sur d'autres machines.

Par exemple, construisons un projet local. Pour ce faire, dans le dossier du projet, exécutez la commande

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug

Voyons ce que cela signifie :

docker courir - la commande de lancement d'image elle-même
-rm - signifie qu'après avoir arrêté le conteneur, il supprime tout ce qui a été créé au cours de sa vie
-v "$PWD":/home/gradle/ - monte le dossier actuel avec notre projet Android dans le dossier interne du conteneur /home/gradle/
-w /home/grade - définit le répertoire de travail du conteneur
Android-build : 5.4.1-28-27 - le nom de notre conteneur que nous avons collecté
gradle assembleDebug - l'équipe de construction elle-même, qui monte notre projet

Si tout se passe bien, après quelques secondes / minutes, vous verrez quelque chose comme CONSTRUIRE AVEC SUCCÈS en 8m 3s! Et dans le dossier app/build/output/apk il y aura une application assemblée.

De même, vous pouvez effectuer d'autres tâches graduelles - vérifier le projet, exécuter des tests, etc. Le principal avantage est que si nous devons construire le projet sur une autre machine, nous n'avons pas à nous soucier de l'installation de l'environnement complet, et il suffira de télécharger l'image nécessaire et d'y exécuter la construction.

Le conteneur ne stocke aucune modification, et chaque assemblage est lancé à partir de zéro, ce qui, d'une part, garantit l'identité de l'assemblage quel que soit l'endroit où il est lancé, d'autre part, à chaque fois que vous devez télécharger toutes les dépendances et compiler à nouveau tout le code, ce qui peut parfois prendre beaucoup de temps. Par conséquent, en plus du démarrage "à froid" habituel, nous avons la possibilité de démarrer l'assemblage tout en maintenant le soi-disant. "cache", où nous enregistrons le dossier ~/.gradle en le copiant simplement dans le dossier de travail du projet, et au début de la prochaine génération, nous le renvoyons. Nous avons déplacé toutes les procédures de copie dans des scripts séparés et la commande de lancement elle-même a commencé à ressembler à ceci

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 de construction moyen du projet a été réduit de plusieurs fois (selon le nombre de dépendances sur le projet, mais le projet moyen a donc commencé à se construire en 1 minute au lieu de 5 minutes).

Tout cela en soi n'a de sens que si vous disposez de votre propre serveur CI / CD interne, que vous supportez vous-même. Mais maintenant, il existe de nombreux services cloud dans lesquels tous ces problèmes sont résolus et vous n'avez pas à vous en soucier, et les propriétés de construction nécessaires peuvent également être spécifiées dans les paramètres du projet.

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Conservez-vous votre système CI/CD en interne ou utilisez-vous un service tiers

  • Utiliser un serveur interne

  • Utiliser un service externe

  • Nous n'utilisons pas CI/CD

  • Autre

42 utilisateurs ont voté. 16 utilisateurs se sont abstenus.

Source: habr.com

Ajouter un commentaire