Lors du développement d'un projet pour la plateforme Android, même le plus petit, tôt ou tard, doit faire face à l'environnement de développement. En plus du SDK Android, vous avez besoin de la dernière version de Kotlin, Gradle, plateforme-tools, build-tools. Et si sur la machine du développeur toutes ces dépendances sont résolues dans une plus grande mesure en utilisant l'IDE Android Studio, alors sur le serveur CI / CD, chaque mise à jour peut se transformer en mal de 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 soi-disant outil de création. "Conteneurs" contenant le noyau minimum du système d'exploitation et l'ensemble de logiciels nécessaire, que nous pouvons déployer où nous voulons, tout en préservant l'environnement. Ce qui sera exactement dans notre conteneur est défini dans le Dockerfile, qui est ensuite assemblé en une image lancée n'importe où et possédant la propriété idempotency.
Le processus d'installation et les bases de Docker sont parfaitement décrits sur son
site officiel . Par conséquent, un peu en avance, nous avons ici 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 démarrons l'assemblage du conteneur avec la commande
docker build -t android-build:5.4-28-27 .
L'
option -t spécifie 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é un ensemble de versions de 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 cette «version».
Une fois l'assembly passé, nous pouvons utiliser notre image localement, nous pouvons la télécharger avec la
commande docker push vers un référentiel d'images public ou privé pour la télécharger sur d'autres machines.
Par exemple, nous collectons le projet localement. Pour ce faire, exécutez la commande dans le dossier du projet
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 run - la commande de lancement d'image elle-même
-rm - signifie qu'après l'arrêt du conteneur, il supprime derrière lui 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 / 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 collecté
gradle assembleDebug - en fait l'équipe de construction qui construit notre projet
Si tout se passe bien, après quelques secondes / minutes, vous verrez sur votre écran quelque chose comme
CONSTRUIRE RÉUSSI en 8m 3s ! Et dans le dossier app / build / output / apk sera l'application assemblée.
De la même manière, vous pouvez effectuer d'autres tâches gradle - vérifier le projet, exécuter des tests, etc. Le principal avantage est que si vous avez besoin de construire le projet sur une autre machine, nous n'avons pas besoin de nous soucier de l'installation de l'environnement complet et il suffira de télécharger l'image nécessaire et d'exécuter l'assemblage.
Le conteneur ne stocke aucune modification et chaque assemblage part de zéro, ce qui garantit d'une part l'identité de l'assemblage quel que soit l'endroit où il a été lancé, d'autre part, chaque fois que vous devez télécharger toutes les dépendances et recompiler à nouveau tout le code, ce qui peut parfois prendre un temps considérable. Par conséquent, en plus du démarrage "à froid" habituel, nous avons la possibilité de démarrer l'assemblage tout en conservant ce que l'on appelle. "Cache", où nous enregistrons le dossier ~ / .gradle simplement en le copiant dans le dossier de travail du projet, et au début de la prochaine génération nous le renvoyons. Nous avons mis 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 moyen de montage du projet pour nous a été réduit plusieurs fois (en fonction du nombre de dépendances sur le projet, mais le projet moyen a donc commencé à se monter en 1 minute au lieu de 5 minutes).
Tout cela en soi n'a de sens que si vous avez votre propre serveur CI / CD interne, dont vous êtes vous-même le support. Mais maintenant, il existe de nombreux services cloud dans lesquels tous ces problèmes ont été résolus et vous n'avez pas à vous en soucier et vous pouvez également spécifier les propriétés d'assemblage nécessaires dans les paramètres du projet.