ProHoster > BLOG > administrare > Construirea unui proiect Android într-un container Docker

Construirea unui proiect Android într-un container Docker

Când dezvoltați un proiect pentru platforma Android, chiar și cel mai mic, mai devreme sau mai târziu trebuie să vă ocupați de mediul de dezvoltare. Pe lângă SDK-ul Android, este necesar să aveți cea mai recentă versiune de Kotlin, Gradle, platform-tools, build-tools. Și dacă pe mașina dezvoltatorului toate aceste dependențe sunt rezolvate într-o măsură mai mare folosind Android Studio IDE, atunci pe serverul CI / CD, fiecare actualizare se poate transforma într-o bătaie de cap. Și dacă în dezvoltarea web, Docker a devenit soluția standard pentru problema mediului, atunci de ce să nu încercați să rezolvați o problemă similară cu ea în dezvoltarea Android...

Pentru cei care nu știu ce este Docker - dacă este destul de simplu, atunci acesta este un instrument pentru a crea așa-numitul. „Containere” care conțin nucleul minim al sistemului de operare și setul necesar de software pe care îl putem implementa oriunde dorim, păstrând în același timp mediul. Ceea ce va fi exact în containerul nostru este determinat în Dockerfile, care este apoi asamblat într-o imagine care poate fi lansată oriunde și are proprietăți de idempotenta.

Procesul de instalare și elementele de bază ale lui Docker sunt descrise frumos pe el site-ul oficial. Prin urmare, privind puțin înainte, avem un astfel de 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"

Îl salvăm în folderul cu proiectul nostru Android și începem să construim containerul cu comanda

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

Parametru -t setează eticheta sau numele containerului nostru, care de obicei constă din numele și versiunea acestuia. În cazul nostru, l-am numit android-build și în versiune am specificat o combinație de versiuni gradle, android-sdk și platform-tools. În viitor, ne va fi mai ușor să căutăm imaginea de care avem nevoie după nume folosind o astfel de „versiune”.

După ce construirea a trecut, ne putem folosi imaginea local, o putem descărca cu comanda docker push la un depozit de imagini public sau privat pentru a le descărca pe alte mașini.

De exemplu, să construim un proiect local. Pentru a face acest lucru, în folderul de proiect, executați comanda

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

Să ne dăm seama ce înseamnă:

docker alerga - comanda de lansare a imaginii în sine
-rm - înseamnă că, după oprirea containerului, șterge tot ce a fost creat în timpul vieții sale
-v „$PWD”:/acasă/gradle/ - montează folderul curent cu proiectul nostru Android în folderul intern al containerului /home/gradle/
-w /home/gradle - setează directorul de lucru al containerului
android-build:5.4.1-28-27 - numele containerului nostru pe care l-am colectat
gradle assembleDebug - echipa de constructii in sine, care asambleaza proiectul nostru

Dacă totul merge bine, atunci după câteva secunde/minute veți vedea ceva de genul CONSTRUIREA DE SUCCES in 8m 3s! Și în folderul app/build/output/apk va fi o aplicație asamblată.

În mod similar, puteți efectua alte sarcini gradle - verificați proiectul, rulați teste etc. Principalul avantaj este că, dacă trebuie să construim proiectul pe orice altă mașină, nu trebuie să ne facem griji cu privire la instalarea întregului mediu și va fi suficient să descărcam imaginea necesară și să rulăm construcția în ea.

Containerul nu stochează nicio modificare, iar fiecare ansamblu este lansat de la zero, ceea ce, pe de o parte, garantează identitatea ansamblului indiferent de locul în care este lansat, pe de altă parte, de fiecare dată când trebuie să descărcați toate dependențele. și compilați din nou tot codul, iar acest lucru poate dura uneori o perioadă semnificativă de timp. Prin urmare, pe lângă pornirea obișnuită „la rece”, avem opțiunea de a porni montajul menținând așa-numitul. „cache”, unde salvăm folderul ~/.gradle prin simpla copiere a acestuia în folderul de lucru al proiectului, iar la începutul următoarei build îl returnăm înapoi. Am mutat toate procedurile de copiere în scripturi separate și comanda de lansare în sine a început să arate așa

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"

Ca urmare, timpul mediu de construire a proiectului a fost redus de câteva ori (în funcție de numărul de dependențe de proiect, dar proiectul mediu a început astfel să se construiască în 1 minut în loc de 5 minute).

Toate acestea în sine au sens numai dacă aveți propriul dvs. server CI/CD intern, pe care îl susțineți însuți. Dar acum există multe servicii cloud în care toate aceste probleme sunt rezolvate și nu trebuie să vă faceți griji pentru asta, iar proprietățile de construcție necesare pot fi specificate și în setările proiectului.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Vă păstrați sistemul CI/CD intern sau utilizați un serviciu terță parte

  • Folosind un server intern

  • Utilizarea unui serviciu extern

  • Nu folosim CI/CD

  • Alte

Au votat 42 de utilizatori. 16 utilizatori s-au abținut.

Sursa: www.habr.com

Adauga un comentariu