Amikor Android platformra fejlesztünk egy projektet, még a legkisebbet is, előbb-utóbb meg kell küzdeni a fejlesztői környezettel. Az Android SDK mellett a Kotlin, Gradle, platform-tools, build-tools legújabb verziójára is szükség van. És ha a fejlesztő gépén mindezek a függőségek nagyobb mértékben megoldódnak az Android Studio IDE segítségével, akkor a CI / CD szerveren minden frissítés fejfájásba fordulhat. És ha a webfejlesztésben a Docker lett a környezetvédelmi probléma standard megoldása, akkor miért ne próbálhatna meg vele egy hasonló problémát megoldani az Android fejlesztésben...
Azok számára, akik nem tudják, mi az a Docker - ha elég egyszerű, akkor ez egy eszköz az ún. "Konténerek", amelyek tartalmazzák a minimális operációs rendszer kernelt és a szükséges szoftverkészletet, amit bárhová telepíthetünk, a környezet karbantartása mellett. Hogy pontosan mi lesz a konténerünkben, azt a Dockerfile határozza meg, amely aztán egy bárhol elindítható, idempotencia tulajdonságokkal rendelkező képpé áll össze.
A telepítési folyamat és a Docker alapjai szépen le vannak írva az övén . Ezért egy kicsit előre tekintve van egy ilyen Dockerfile-unk
# Т.к. основным инструментом для сборки 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"
Mentjük a mappába az Android projektünkkel, és a paranccsal elkezdjük építeni a tárolót
docker build -t android-build:5.4-28-27 .Paraméter -t beállítja a tárolónk címkéjét vagy nevét, amely általában a nevéből és verziójából áll. Esetünkben android-build-nek hívtuk, a verzióban pedig a gradle, android-sdk és platform-tools verziók kombinációját adtuk meg. A jövőben könnyebben fogunk név szerint keresni a számunkra szükséges képet egy ilyen „verzió” segítségével.
A build lefutása után a képünket helyben használhatjuk, a paranccsal letölthetjük dokkoló push nyilvános vagy privát képtárba, hogy letölthesse más gépekre.
Példaként építsünk fel egy helyi projektet. Ehhez futtassa a parancsot a projekt mappájában
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebugNézzük meg, mit jelent:
docker fut - maga a képindítási parancs
-rm - azt jelenti, hogy a konténer leállítása után mindent törl, ami élete során keletkezett
-v "$PWD":/home/gradle/ - csatolja az aktuális mappát az Android projektünkkel a konténer belső /home/gradle/ mappájába
-w /home/gradle - beállítja a tároló munkakönyvtárát
android-build:5.4.1-28-27 - az általunk összegyűjtött konténerünk neve
gradle assembleDebug - maga a build csapat, amely összeállítja a projektünket
Ha minden jól megy, akkor néhány másodperc / perc múlva valami hasonlót fog látni SIKERES ÉPÍTÉS 8m 3 s alatt! Az app/build/output/apk mappában pedig egy összerakott alkalmazás lesz.
Hasonlóképpen más fokozati feladatokat is végrehajthat - ellenőrizheti a projektet, futtathat teszteket stb. Legfőbb előnye, hogy ha bármilyen másik gépen kell felépíteni a projektet, akkor nem kell a teljes környezet telepítésével törődnünk, elég lesz letölteni a szükséges képfájlt és abban futtatni a buildet.
A konténer nem tárol semmilyen változást, és minden összeállítás a nulláról indul, ami egyrészt garantálja az összeállítás azonosságát, függetlenül attól, hogy honnan indult, másrészt minden alkalommal, amikor le kell töltenie az összes függőséget és fordítsa le újra az összes kódot, és ez néha jelentős időt vehet igénybe. Ezért a szokásos „hideg” indítás mellett lehetőségünk van a szerelés elindítására, miközben fenntartjuk az ún. "cache", ahol a ~/.gradle mappát úgy mentjük el, hogy egyszerűen átmásoljuk a projekt munkamappájába, majd a következő build elején visszaadjuk. Az összes másolási eljárást külön szkriptekbe helyeztük át, és maga az indítási parancs kezdett így kinézni
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"Ennek eredményeként az átlagos projektépítési idő többszörösére csökkent (a projektfüggőségek számától függően, de az átlagos projekt így 1 perc helyett 5 perc alatt kezdett felépülni).
Mindez önmagában csak akkor van értelme, ha rendelkezik saját belső CI / CD szerverrel, amelyet Ön is támogat. De ma már számos felhőszolgáltatás létezik, amelyekben mindezek a problémák megoldódnak, és nem kell aggódni miatta, és a szükséges build tulajdonságok is megadhatók a projektbeállításokban.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Belső CI/CD-rendszerét tartja, vagy harmadik féltől származó szolgáltatást vesz igénybe?
-
Belső szerver használata
-
Külső szolgáltatás használata
-
Nem használunk CI/CD-t
-
Más
42 felhasználó szavazott. 16 felhasználó tartózkodott.
Forrás: will.com