Construír un proxecto de Android nun contedor Docker

Cando se desenvolve un proxecto para a plataforma Android, aínda que sexa o máis pequeno, tarde ou cedo tes que ocuparte do entorno de desenvolvemento. Ademais do SDK de Android, é necesario ter a última versión de Kotlin, Gradle, platform-tools, build-tools. E se na máquina do programador todas estas dependencias resólvense en maior medida usando o IDE de Android Studio, entón no servidor CI/CD cada actualización pode converterse nunha dor de cabeza. E se no desenvolvemento web Docker converteuse na solución estándar para o problema do medio ambiente, entón por que non tentar resolver un problema similar no desenvolvemento de Android usándoo...

Para quen non saiba o que é Docker, por dicilo de forma sinxela, é unha ferramenta para crear o chamado. "contedores" que conteñen un núcleo mínimo do sistema operativo e o conxunto de software necesario que podemos implantar onde queiramos, preservando o medio ambiente. O que estará exactamente no noso contedor determínase no Dockerfile, que despois se ensambla nunha imaxe que se pode lanzar en calquera lugar e ten propiedades de idempotencia.

O proceso de instalación e os conceptos básicos de Docker descríbense perfectamente no seu sitio web oficial. Polo tanto, mirando un pouco cara adiante, este é o Dockerfile co que acabamos:

# Т.к. основным инструментом для сборки 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"

Gardamos no cartafol co noso proxecto Android e comezamos a construír o contedor co comando

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

Parámetro -t especifica a etiqueta ou o nome do noso contedor, que normalmente consta do seu nome e versión. No noso caso, chamámoslle android-build e na versión indicamos un conxunto de versións de gradle, android-sdk e platform-tools. No futuro, será máis fácil para nós buscar a imaxe que necesitamos polo nome usando esta "versión".

Despois de completar a montaxe, podemos usar a nosa imaxe localmente, podemos descargala co comando docker push a un repositorio de imaxes público ou privado para descargalo noutras máquinas.

Como exemplo, imos construír un proxecto localmente. Para iso, executa o comando no cartafol co proxecto

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

Imos descubrir o que significa:

executar docker - o propio comando de lanzamento da imaxe
-rm — significa que despois de que o contedor se deteña, elimina todo o que se creou durante a súa vida útil
-v "$PWD":/home/gradle/ — monta o cartafol actual co noso proxecto de Android no cartafol do contedor interno /home/gradle/
-w /home/gradle — especifica o directorio de traballo do contedor
Android-build: 5.4.1-28-27 — o nome do noso recipiente que recollemos
gradle assembleDebug — o equipo de montaxe real que monta o noso proxecto

Se todo vai ben, nun par de segundos/minutos verás algo así na túa pantalla CONSTRUCCIÓN EXITOSA en 8m 3s! E o cartafol app/build/output/apk conterá a aplicación ensamblada.

Podes realizar outras tarefas de gradle dun xeito similar: comprobar o proxecto, realizar probas, etc. A principal vantaxe é que se necesitamos construír o proxecto en calquera outra máquina, non necesitamos preocuparnos por instalar todo o ambiente e será suficiente descargar a imaxe necesaria e executar a compilación nela.

O contedor non almacena ningún cambio, e cada montaxe lánzase dende cero, o que, por unha banda, garante a identidade da montaxe independentemente de onde se lance, por outra banda, cada vez que hai que descargar todas as dependencias. e recompila todo o código de novo, e isto ás veces pode levar moito tempo. Polo tanto, ademais do habitual arranque "en frío", temos a opción de iniciar a compilación mentres gardamos o chamado. "caché", onde gardamos o cartafol ~/.gradle simplemente copiándoo no cartafol de traballo do proxecto, e ao comezo da seguinte compilación devolvémolo de volta. Movemos todos os procedementos de copia en scripts separados e o propio comando de inicio comezou a verse así

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"

Como resultado, o tempo medio de construción do noso proxecto reduciuse varias veces (dependendo do número de dependencias do proxecto, pero o proxecto medio comezou así a montarse en 1 minuto en lugar de 5 minutos).

Todo isto, por suposto, só ten sentido se tes o teu propio servidor CI/CD interno, que ti apoias. Pero agora hai moitos servizos na nube nos que se solucionan todos estes problemas e non tes que preocuparte por iso, e as propiedades de montaxe necesarias tamén se poden especificar na configuración do proxecto.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Mantén o seu sistema CI/CD na casa ou utiliza un servizo de terceiros?

  • Usamos un servidor interno

  • Utilizamos un servizo externo

  • Non usamos CI/CD

  • Outro

Votaron 42 usuarios. 16 usuarios abstivéronse.

Fonte: www.habr.com

Engadir un comentario