🥇Androidi projekti koostamine Docker-konteineris

Androidi platvormile projekti arendamine, isegi väikseima, toob varem või hiljem esile arenduskeskkonna. Lisaks Android SDK-le on vajalik ka uusim versioon Kotlinist, Gradlest, platform-tools'ist ja build-tools'ist. Kui arendaja masinas lahendatakse kõik need sõltuvused suuresti Android Studio IDE abil, siis CI/CD serveris võivad iga uuenduse puhul tekkida peavalud. Ja kui veebiarenduses on keskkonnaprobleemide lahendamiseks standardiks saanud Docker, siis miks mitte proovida sarnast probleemi lahendada ka Android-arenduses…

Neile, kes ei tea, mis on Docker — kui väga lihtsalt öelda, siis see on tööriist nn "konteinerite" loomiseks, kus sisaldub minimaalne OS-i tuum ja vajalik tarkvarapakett, mida me saame käivitada seal, kus tahame, säilitades samal ajal keskkonna. Mida täpselt meie konteineris on, määratakse Dockerfile'is, misjärel koostatakse see pilt, mida saab käitada igal pool ja millel on idempotentsuse omadused.

Docker'i installimise ja aluste koondamine on suurepäraselt kirjas selle ametlikul kodulehe. Seega, natuke ette kaardistades, selline Dockerfile meil on.

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

Salvestame selle meie Android-projekti kausta ja käivitame konteineri koostamise käsuga

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

Parameeter -t määraab tag või konteineri nimi, mis tavaliselt koosneb oma nimetusest ja versioonist. Meie puhul nimetati see android-build ja versioonis määrati gradle, android-sdk ja platform-tools kogum. Edasi muutub meil lihtsamaks otsida vajalikku pilti nime kaudu, kasutades sellist "versiooni".

Pärast koostamise lõppu saame meie pilti kasutada kohalikult, saame laadida selle käsuga docker push avalikku või privaatset piltide reposi, et laadida see teistesse masinatesse.

Näiteks koondame kohaliku projekti. Selleks täidame projektikaustas käsu

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

Analüüsime, mida see tähendab:

docker run — piltide käivitamise käsk
-rm — tähendab, et pärast konteineri peatamist eemaldab see kõik, mis tema elu jooksul loodi
-v "$PWD":/home/gradle/ — monteerib praeguse kausta meie Android-projektiga konteineri sisemisse kausta /home/gradle/
-w /home/gradle — määrab konteineri töökausta
android-build:5.4.1-28-27 — meie kogutud konteineri nimi
gradle assembleDebug — ehitamise käsk, mis kogub meie projekti

Kui kõik läheb hästi, siis näete mõne sekundi/minuti pärast ekraanil midagi sellist BUILD SUCCESSFUL in 8m 3s! Ja kaustas app/build/output/apk asub kogutud rakendus.

Sarnasel viisil saab täita ka muid gradle ülesandeid — kontrollida projekti, käivitada teste jne. Peamine eelis on see, et projekti kogumiseks mis tahes teisel masinal ei pea me muretsema kogu keskkonna seadistamise pärast, piisab, kui laadime vajalikku pilti ja käivitame seal kogumise.

Konteiner ei salvesta mingeid muudatusi ning iga kogumine käivitatakse nullist, mis tagab ehituse identiteedi olenemata käivitamise kohast. Samas tuleb iga kord alla laadida kõik sõltuvused ja kompileerida kogu kood uuesti, mis võib võtta märkimisväärselt aega. Seetõttu on lisaks tavalisest „külmast“ käivitamisest meil võimalus käivitada kogemist koos nn „vahekogudega“, kus me salvestame kausta ~/ .gradle lihtsalt kopeerides selle projekti töökatalooge, ja järgmise kogimise alguses toome selle tagasi. Kõik kopeerimise protseduurid oleme viinud eraldi skriptidesse ja meie käivituskommando on nüüd selline

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"

Kokkuvõttes on meie projekti kogumise keskmine aeg lühenenud mitu korda (sõltuvalt projekti sõltuvustest, kuid keskmine projekt on niimoodi hakanud koguma 1 minutiga, mitte 5 minutiga).

Kogu see asi on mõistlik ainult siis, kui teil on oma sisemine CI/CD server, mille hoolduse eest te ise hoolitsete. Kuid praegu on palju pilveteenuseid, kus kõik need probleemid on lahendatud ja te ei pea selle pärast muretsema ning vajalikke ehituse omadusi saab samuti määrata projekti seadetes.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas hoiate CI/CD süsteemi sees või kasutate kolmandat osapoolte teenust

Kasutame sisemist serverit
Kasutame välist teenust
Ei kasuta CI/CD-d
Teine

Hääletas 42 kasutajat. Vaidlesid 16 kasutajat.

Allikas: habr.com