Распрацоўваючы праект пад платформу Android, нават самы невялікі, рана ці позна даводзіцца сутыкацца з асяроддзем для распрацоўкі. Акрамя Android SDK, неабходна, каб была апошняя версія Kotlin, Gradle, platform-tools, build-tools. І калі на машыне распрацоўніка ўсе гэтыя залежнасці вырашаюцца ў большай меры з дапамогай Android Studio IDE, то на серверы CI/CD кожнае абнаўленне можа ператварыцца ў галаўны боль. І калі ў web-распрацоўцы, рашэннем праблемы асяроддзя стандартам стаў Docker, то чаму-то не паспрабаваць вырашыць з дапамогай яго аналагічную праблему і ў Android-распрацоўцы…
Для тых, хто не ведае што такое Docker – калі зусім проста, то гэта прылада стварэння т.зв. "кантэйнераў" дзе ўтрымоўваецца мінімальнае ядро АС і неабходны набор ПА, якія мы можам разгортваць дзе захочам, захоўваючы пры гэтым асяроддзе. Што менавіта будзе ў нашым кантэйнеры вызначаецца ў Dockerfile, які потым збіраецца ў выяву які запускаецца дзе заўгодна і які валодае ўласцівасці ідэмпатэнтнасці.
Працэс усталёўкі і асновы Docker выдатна апісаны на яго
# Т.к. основным инструментом для сборки 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"
Захоўваем яго ў тэчку з нашым Android-праектам і запускаем зборку кантэйнера камандай
docker build -t android-build:5.4-28-27 .
Параметр -t задае tag ці імя нашага кантэйнера, якое звычайна складаецца з яго назву і версіі. У нашым выпадку мы назвалі яго android-build, а ў версіі паказалі сукупнасць версій gradle, android-sdk і platform-tools. У далейшым нам прасцей будзе шукаць патрэбны нам вобраз па імені выкарыстоўваючы такую "версію".
Пасля таго як зборка прайшла мы можам выкарыстоўваць нашу выяву лакальна, можам загрузіць яго камандай docker push у публічны або прыватны рэпазітар вобразаў каб спампоўваць яго на іншыя машыны.
У якасці прыкладу збяром лакальна праект. Для гэтага ў тэчцы з праектам выканаем каманду
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug
Разбяром што яна азначае:
докер прабег - сама каманда запуску выявы
-rm - азначае што пасля прыпынку кантэйнера ён выдаляе за сабой усё што стваралася ў працэсе яго жыцця
-v $PWD:/home/gradle/ - мантуе бягучую тэчку з нашым Android-праектам ва ўнутраную тэчку кантэйнера /home/gradle/
-w /home/gradle - задае працоўную дырэкторыю кантэйнера
android-build:5.4.1-28-27 - імя нашага кантэйнера, які мы сабралі
gradle assembleDebug - уласна каманда зборкі, якая збірае наш праект
Калі ўсё скласціся ўдала, то праз пару секунд/хвілін вы ўбачыце ў сябе на экране нешта накшталт BUILD SUCCESSFUL in 8m 3s! А ў тэчцы app/build/output/apk будзе ляжаць сабранае прыкладанне.
Аналагічнай выявай можна выконваць іншыя задачы gradle - правяраць праект, запускаць тэсты і г.д. Асноўная перавага — пры неабходнасці зборкі праекта на любой іншай машыне, нам не трэба турбавацца аб усталёўцы ўсяго асяроддзя і досыць будзе спампаваць неабходную выяву і запусціць у ім зборку.
Кантэйнер не захоўвае ніякіх змен, і кожная зборка запускаецца з нуля, што з аднаго боку гарантуе ідэнтычнасць зборкі незалежна ад месца яе запуску, з іншага боку кожны раз даводзіцца спампоўваць усе залежнасці і кампіляваць увесь код нанова, а гэта часам можа займаць істотны час. Таму акрамя звычайнага халоднага запуску ў нас ёсць варыянт запуску зборкі з захаваннем т.зв. "кэша", дзе мы захоўваем тэчку ~/.gradle проста капіюючы яе ў працоўную тэчку праекту, а ў пачатку наступнай зборкі вяртаем яе зваротна. Усе працэдуры капіравання мы вынеслі ў асобныя скрыпты і сама каманда запуску ў нас стала выглядаць так
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"
У выніку, сярэдні час зборкі праекту ў нас скараціўся ў некалькі разоў (у залежнасці ад колькасці залежнасцяў на праекце, але сярэдні праект такім чынам стаў збірацца за 1 хвіліну замест 5 хвілін).
Усё гэта само сабой мае сэнс толькі калі ў вас есць уласны ўнутраны CI/CD сервер, падтрымкай якога вы самі і займаецеся. Але цяпер ёсць шмат хмарных сэрвісаў у якіх усе гэтыя праблемы вырашаны і вам не трэба пра гэта перажываць і патрэбныя ўласцівасці зборкі можна гэтак жа ўказаць у наладах праекта.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні.
Ці трымаеце вы сістэму CI/CD усярэдзіне ці карыстаецеся іншым сэрвісам
-
Выкарыстоўваны ўнутраны сервер
-
Выкарыстоўваны знешні сэрвіс
-
Не выкарыстоўваем CI/CD
-
Іншая
Прагаласавалі 42 карыстальніка. Устрымаліся 16 карыстальнікаў.
Крыніца: habr.com