Bygge et Android-prosjekt i en Docker-beholder

Når du utvikler et prosjekt for Android-plattformen, selv den minste, må du før eller siden forholde deg til utviklingsmiljøet. I tillegg til Android SDK, er det nødvendig å ha den nyeste versjonen av Kotlin, Gradle, plattformverktøy, byggeverktøy. Og hvis på utviklerens maskin alle disse avhengighetene løses i større grad ved hjelp av Android Studio IDE, så på CI / CD-serveren, kan hver oppdatering bli til en hodepine. Og hvis i webutvikling har Docker blitt standardløsningen på miljøproblemet, hvorfor ikke prøve å løse et lignende problem med det i Android-utvikling ...

For de som ikke vet hva Docker er – hvis det er ganske enkelt, så er dette et verktøy for å lage den såkalte. "Containere" som inneholder minimum OS-kjernen og det nødvendige settet med programvare som vi kan distribuere hvor vi vil, samtidig som vi opprettholder miljøet. Hva som nøyaktig skal være i beholderen vår bestemmes i Dockerfilen, som deretter settes sammen til et bilde som kan lanseres hvor som helst og har idempotensegenskaper.

Installasjonsprosessen og det grunnleggende om Docker er vakkert beskrevet på hans offisiell nettside. Derfor, ser vi litt fremover, har vi en slik 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 lagrer den i mappen med Android-prosjektet vårt og begynner å bygge beholderen med kommandoen

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

Parameter -t angir taggen eller navnet på beholderen vår, som vanligvis består av navnet og versjonen. I vårt tilfelle kalte vi det android-build og i versjonen spesifiserte vi en kombinasjon av gradle, android-sdk og plattformverktøy-versjoner. I fremtiden vil det være lettere for oss å søke etter bildet vi trenger ved navn ved å bruke en slik "versjon".

Etter at byggingen er bestått, kan vi bruke bildet vårt lokalt, vi kan laste det ned med kommandoen docker push til et offentlig eller privat bildelager for å laste det ned til andre maskiner.

Som et eksempel, la oss bygge et lokalt prosjekt. For å gjøre dette, kjør kommandoen i prosjektmappen

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

La oss finne ut hva det betyr:

docker kjøre - selve bildestartskommandoen
Rm - betyr at etter å ha stoppet beholderen, sletter den alt som ble opprettet i løpet av dens levetid
-v "$PWD":/home/gradle/ - monterer gjeldende mappe med vårt Android-prosjekt til containerens interne mappe /home/gradle/
-w /home/gradle - setter arbeidskatalogen til beholderen
android-bygg:5.4.1-28-27 - navnet på containeren vår som vi har samlet inn
gradle assembleDebug - byggeteamet selv, som setter sammen prosjektet vårt

Hvis alt går bra, vil du etter et par sekunder / minutter se noe som BYGG SUKSESSFULLT på 8m 3s! Og i app/build/output/apk-mappen vil det være en samlet applikasjon.

På samme måte kan du utføre andre gradelle oppgaver - sjekke prosjektet, kjøre tester, etc. Den største fordelen er at hvis vi trenger å bygge prosjektet på en annen maskin, trenger vi ikke å bekymre oss for å installere hele miljøet, og det vil være nok til å laste ned det nødvendige bildet og kjøre byggingen i det.

Containeren lagrer ingen endringer, og hver sammenstilling startes fra bunnen av, noe som på den ene siden garanterer identiteten til sammenstillingen uavhengig av hvor den lanseres, på den annen side hver gang du skal laste ned alle avhengighetene og kompiler all koden på nytt, og dette kan noen ganger ta betydelig tid. Derfor har vi, i tillegg til vanlig «kald» start, muligheten til å starte monteringen samtidig som vi opprettholder den såkalte. "cache", hvor vi lagrer ~/.gradle-mappen ved ganske enkelt å kopiere den til arbeidsmappen til prosjektet, og i begynnelsen av neste bygg returnerer vi den tilbake. Vi flyttet alle kopieringsprosedyrer til separate skript, og selve lanseringskommandoen begynte å se slik ut

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 et resultat ble den gjennomsnittlige prosjektbyggetiden redusert med flere ganger (avhengig av antall avhengigheter på prosjektet, men det gjennomsnittlige prosjektet begynte dermed å bygge på 1 minutt i stedet for 5 minutter).

Alt dette i seg selv gir bare mening hvis du har din egen interne CI/CD-server, som du selv støtter. Men nå er det mange skytjenester der alle disse problemene er løst, og du trenger ikke å bekymre deg for det, og de nødvendige byggeegenskapene kan også spesifiseres i prosjektinnstillingene.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Holder du CI/CD-systemet internt eller bruker du en tredjepartstjeneste

  • Bruke en intern server

  • Bruke en ekstern tjeneste

  • Vi bruker ikke CI/CD

  • andre

42 brukere stemte. 16 brukere avsto.

Kilde: www.habr.com

Legg til en kommentar