ProHoster > Blog > administration > Opbygning af et Android-projekt i en Docker-container

Opbygning af et Android-projekt i en Docker-container

Når man udvikler et projekt til Android-platformen, selv det mindste, skal man før eller siden forholde sig til udviklingsmiljøet. Ud over Android SDK er det nødvendigt at have den nyeste version af Kotlin, Gradle, platform-tools, build-tools. Og hvis alle disse afhængigheder på udviklerens maskine løses i højere grad ved hjælp af Android Studio IDE, så på CI / CD-serveren kan hver opdatering blive til en hovedpine. Og hvis Docker i webudvikling er blevet standardløsningen på miljøproblemet, hvorfor så ikke prøve at løse et lignende problem med det i Android-udvikling ...

For dem der ikke ved hvad Docker er – hvis det er ret simpelt, så er dette et værktøj til at skabe den såkaldte. "Containere", som indeholder minimum OS-kernen og det nødvendige sæt software, som vi kan implementere, hvor vi vil, og samtidig bevare miljøet. Hvad der præcist vil være i vores container, bestemmes i Dockerfilen, som derefter samles til et billede, der kan lanceres hvor som helst og har idempotensegenskaber.

Installationsprocessen og det grundlæggende i Docker er smukt beskrevet på hans det officielle site. Derfor, ser vi lidt fremad, har vi sådan en 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"

Vi gemmer det i mappen med vores Android-projekt og begynder at bygge beholderen med kommandoen

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

Parameter -t angiver tagget eller navnet på vores container, som normalt består af dens navn og version. I vores tilfælde kaldte vi det android-build og i versionen specificerede vi en kombination af gradle, android-sdk og platform-tools versioner. I fremtiden vil det være lettere for os at søge efter det billede, vi har brug for ved navn, ved at bruge sådan en "version".

Efter at bygningen er bestået, kan vi bruge vores billede lokalt, vi kan downloade det med kommandoen docker push til et offentligt eller privat billedlager for at downloade det til andre maskiner.

Lad os som et eksempel bygge et lokalt projekt. For at gøre dette skal du køre kommandoen i projektmappen

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

Lad os finde ud af, hvad det betyder:

docker løb - selve billedstartskommandoen
-rm - betyder, at efter at have stoppet beholderen, sletter den alt, hvad der blev skabt i løbet af dens levetid
-v "$PWD":/home/gradle/ - monterer den aktuelle mappe med vores Android-projekt til containerens interne mappe /home/gradle/
-w /home/gradle - indstiller containerens arbejdsmappe
android-build:5.4.1-28-27 - navnet på vores container, som vi har indsamlet
gradle assembleDebug - byggeteamet selv, som samler vores projekt

Hvis alt går godt, vil du efter et par sekunder / minutter se noget lignende BYG SUCCES på 8m 3s! Og i app/build/output/apk-mappen vil der være en samlet applikation.

På samme måde kan du udføre andre gradelle opgaver - tjekke projektet, køre tests osv. Den største fordel er, at hvis vi skal bygge projektet på en hvilken som helst anden maskine, behøver vi ikke at bekymre os om at installere hele miljøet, og det vil være nok til at downloade det nødvendige billede og køre buildet i det.

Containeren gemmer ingen ændringer, og hver samling startes fra bunden, hvilket på den ene side garanterer forsamlingens identitet uanset hvor den startes, på den anden side hver gang du skal downloade alle afhængigheder og kompiler al koden igen, og dette kan nogle gange tage en betydelig mængde tid. Derfor har vi, udover den sædvanlige "kold" start, mulighed for at starte montagen samtidig med at den såkaldte. "cache", hvor vi gemmer ~/.gradle-mappen ved blot at kopiere den til projektets arbejdsmappe, og i begyndelsen af ​​næste build returnerer vi den tilbage. Vi flyttede alle kopieringsprocedurer til separate scripts, og selve startkommandoen begyndte at se sådan ud

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"

Som følge heraf blev den gennemsnitlige projektbyggetid reduceret med flere gange (afhængigt af antallet af afhængigheder af projektet, men det gennemsnitlige projekt begyndte således at bygge på 1 minut i stedet for 5 minutter).

Alt dette i sig selv giver kun mening, hvis du har din egen interne CI/CD-server, som du selv understøtter. Men nu er der mange cloud-tjenester, hvor alle disse problemer er løst, og du behøver ikke bekymre dig om det, og de nødvendige byggeegenskaber kan også angives i projektindstillingerne.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Holder du dit CI/CD-system internt eller bruger du en tredjepartstjeneste

  • Brug af en intern server

  • Brug af en ekstern tjeneste

  • Vi bruger ikke CI/CD

  • Andet

42 brugere stemte. 16 brugere undlod at stemme.

Kilde: www.habr.com

Tilføj en kommentar