ProHoster > Blog > administratë > Ndërtimi i një projekti Android në një kontejner Docker

Ndërtimi i një projekti Android në një kontejner Docker

Kur zhvilloni një projekt për platformën Android, qoftë edhe më të voglin, herët a vonë duhet të merreni me mjedisin e zhvillimit. Përveç Android SDK, është e nevojshme të keni versionin më të fundit të Kotlin, Gradle, platforma-tools, build-tools. Dhe nëse në makinën e zhvilluesit të gjitha këto varësi zgjidhen në një masë më të madhe duke përdorur Android Studio IDE, atëherë në serverin CI / CD, çdo përditësim mund të kthehet në një dhimbje koke. Dhe nëse në zhvillimin e uebit, Docker është bërë zgjidhja standarde për problemin e mjedisit, atëherë pse të mos përpiqeni të zgjidhni një problem të ngjashëm me të në zhvillimin e Android ...

Për ata që nuk e dinë se çfarë është Docker - nëse është mjaft e thjeshtë, atëherë ky është një mjet për krijimin e të ashtuquajturit. "Kontejnerët" të cilët përmbajnë bërthamën minimale të OS dhe grupin e nevojshëm të softuerit që mund t'i vendosim kudo që duam, duke ruajtur mjedisin. Çfarë saktësisht do të jetë në kontejnerin tonë përcaktohet në Dockerfile, i cili më pas grumbullohet në një imazh që mund të lëshohet kudo dhe ka veti idempotencës.

Procesi i instalimit dhe bazat e Docker janë përshkruar bukur në të faqen zyrtare të internetit. Prandaj, duke parë pak përpara, ne kemi një Dockerfile të tillë

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

E ruajmë atë në dosje me projektin tonë Android dhe fillojmë të ndërtojmë kontejnerin me komandën

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

Parametër -t vendos etiketën ose emrin e kontejnerit tonë, i cili zakonisht përbëhet nga emri dhe versioni i tij. Në rastin tonë, ne e quajtëm atë android-build dhe në version specifikuam një kombinim të versioneve gradle, android-sdk dhe platformë-tools. Në të ardhmen, do të jetë më e lehtë për ne të kërkojmë imazhin që na nevojitet me emër duke përdorur një "version" të tillë.

Pasi të ketë kaluar ndërtimi, ne mund ta përdorim imazhin tonë në nivel lokal, mund ta shkarkojmë atë me komandën shtytje docker në një depo imazhesh publike ose private për ta shkarkuar atë në makina të tjera.

Si shembull, le të ndërtojmë një projekt lokal. Për ta bërë këtë, në dosjen e projektit, ekzekutoni komandën

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

Le të kuptojmë se çfarë do të thotë:

drejtues dokeri - vetë komanda e nisjes së imazhit
-rm - do të thotë që pas ndalimit të kontejnerit, ai fshin gjithçka që është krijuar gjatë jetës së tij
-v "$PWD":/home/gradle/ - monton dosjen aktuale me projektin tonë Android në dosjen e brendshme të kontejnerit /home/gradle/
-w /home/gradle - vendos direktorinë e punës së kontejnerit
android-build: 5.4.1-28-27 - emrin e kontejnerit tonë që kemi mbledhur
gradle assembleDebug - vetë ekipi i ndërtimit, i cili mbledh projektin tonë

Nëse gjithçka shkon mirë, atëherë pas disa sekondash / minutash do të shihni diçka të tillë NDËRTIMI I SUKSESSHËM në 8m 3s! Dhe në dosjen app/build/output/apk do të ketë një aplikacion të montuar.

Në mënyrë të ngjashme, ju mund të kryeni detyra të tjera të shkallës - kontrolloni projektin, ekzekutoni testet, etj. Avantazhi kryesor është se nëse duhet të ndërtojmë projektin në ndonjë makinë tjetër, nuk kemi nevojë të shqetësohemi për instalimin e të gjithë mjedisit dhe do të mjaftojë të shkarkojmë imazhin e nevojshëm dhe të ekzekutojmë ndërtimin në të.

Kontejneri nuk ruan asnjë ndryshim dhe çdo montim lëshohet nga e para, gjë që nga njëra anë garanton identitetin e montimit pavarësisht se ku është nisur, nga ana tjetër, sa herë që duhet të shkarkoni të gjitha varësitë. dhe përpiloni të gjithë kodin përsëri, dhe kjo ndonjëherë mund të marrë një sasi të konsiderueshme kohe. Prandaj, përveç fillimit të zakonshëm "të ftohtë", kemi mundësinë e fillimit të montimit duke ruajtur të ashtuquajturën. "cache", ku ruajmë dosjen ~/.gradle thjesht duke e kopjuar në dosjen e punës të projektit dhe në fillim të ndërtimit të radhës e kthejmë atë përsëri. Ne i zhvendosëm të gjitha procedurat e kopjimit në skripta të veçantë dhe vetë komanda e nisjes filloi të dukej kështu

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"

Si rezultat, koha mesatare e ndërtimit të projektit u zvogëlua me disa herë (në varësi të numrit të varësive nga projekti, por projekti mesatar filloi të ndërtohej në 1 minutë në vend të 5 minutave).

E gjithë kjo në vetvete ka kuptim vetëm nëse keni serverin tuaj të brendshëm CI / CD, të cilin ju vetë e mbështesni. Por tani ka shumë shërbime cloud në të cilat zgjidhen të gjitha këto probleme dhe nuk duhet të shqetësoheni për këtë, dhe vetitë e nevojshme të ndërtimit mund të specifikohen gjithashtu në cilësimet e projektit.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem

A e mbani sistemin tuaj CI/CD të brendshëm apo përdorni një shërbim të palës së tretë

  • Përdorimi i një serveri të brendshëm

  • Përdorimi i një shërbimi të jashtëm

  • Ne nuk përdorim CI/CD

  • Tjetër

42 përdorues kanë votuar. 16 përdorues abstenuan.

Burimi: www.habr.com

Shto një koment