Kiam vi disvolvas projekton por la Android-platformo, eĉ la plej malgranda, pli aŭ malpli frue vi devas trakti la evolumedion. Krom la Android SDK, necesas havi la lastan version de Kotlin, Gradle, platform-iloj, konstru-iloj. Kaj se sur la maŝino de la programisto ĉiuj ĉi tiuj dependecoj estas solvitaj en pli granda mezuro per la Android Studio IDE, tiam sur la CI/CD-servilo ĉiu ĝisdatigo povas iĝi kapdoloro. Kaj se en retejo-disvolviĝo Docker fariĝis la norma solvo al la medioproblemo, kial ne provi solvi similan problemon en Android-disvolviĝo uzante ĝin...
Por tiuj, kiuj ne scias, kio estas Docker, por diri simple, ĝi estas ilo por krei la tn. "ujoj" kiuj enhavas minimuman OS-kernon kaj la necesan aron da programaro, kiun ni povas disfaldi kien ni volas, konservante la medion. Kio ekzakte estos en nia ujo estas determinita en la Dockerfile, kiu tiam estas kunvenita en bildon kiu povas esti lanĉita ie ajn kaj havas idempotencajn ecojn.
La instala procezo kaj bazoj de Docker estas perfekte priskribitaj en lia . Tial, rigardante iom antaŭen, ĉi tiu estas la Dockerfile, kun kiu ni finis:
# Т.к. основным инструментом для сборки 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"
Ni konservas ĝin en la dosierujo kun nia Android-projekto kaj komencas konstrui la ujon per la komando
docker build -t android-build:5.4-28-27 .Parametro -t precizigas la etikedon aŭ nomon de nia ujo, kiu kutime konsistas el ĝia nomo kaj versio. En nia kazo, ni nomis ĝin android-build kaj en la versio ni indikis aron da versioj de gradle, android-sdk kaj platform-iloj. Estonte, estos pli facile por ni serĉi la bildon, kiun ni bezonas laŭnome uzante ĉi tiun "version".
Post kiam la asembleo finiĝis, ni povas uzi nian bildon loke, ni povas elŝuti ĝin per la komando docker push al publika aŭ privata bilddeponejo por elŝuti ĝin al aliaj maŝinoj.
Ekzemple, ni konstruu projekton loke. Por fari tion, en la dosierujo kun la projekto, rulu la komandon
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebugNi eltrovu, kion ĝi signifas:
Docker kuri - la bildo-lanĉa komando mem
-rm — signifas, ke post kiam la ujo ĉesas, ĝi forigas ĉion, kio estis kreita dum sia vivo
-v "$PWD":/home/gradle/ — muntas la nunan dosierujon kun nia Android-projekto en la internan ujo-dosierujon /home/gradle/
-w /hejmo/gradle — specifas la labordosierujon de la ujo
android-konstruo:5.4.1-28-27 — la nomo de nia ujo, kiun ni kolektis
gradle assembleDebug — la fakta asemblea teamo kiu kunvenas nian projekton
Se ĉio iras bone, tiam post kelkaj sekundoj/minutoj vi vidos sur via ekrano ion similan KONSTRUU SUKCESE en 8m 3s! Kaj la dosierujo app/build/output/apk enhavos la kunmetitan aplikaĵon.
Vi povas plenumi aliajn gradajn taskojn simile - kontroli la projekton, ruli testojn ktp. La ĉefa avantaĝo estas, ke se ni bezonas konstrui la projekton sur iu ajn alia maŝino, ni ne bezonas zorgi pri instalo de la tuta medio kaj sufiĉos elŝuti la necesan bildon kaj ruli la konstruon en ĝi.
La ujo ne konservas ŝanĝojn, kaj ĉiu aro estas lanĉita de nulo, kio, unuflanke, garantias la identecon de la aro sendepende de kie ĝi estas lanĉita, aliflanke, ĉiufoje vi devas elŝuti ĉiujn dependecojn. kaj kompilu la tutan kodon denove, kaj tio foje povas preni signifan tempon. Tial, krom la kutima "malvarma" komenco, ni havas la eblon komenci la konstruon dum konservado de la tn. "kaŝmemoro", kie ni konservas la ~/.gradle-dosierujon simple kopiante ĝin al la labordosierujo de la projekto, kaj komence de la sekva konstruo ni resendas ĝin. Ni movis ĉiujn kopiajn procedurojn en apartajn skriptojn kaj la lanĉa komando mem komencis aspekti tiel
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"Kiel rezulto, nia averaĝa projekto-konstrutempo estis reduktita plurfoje (depende de la nombro da dependecoj de la projekto, sed la meza projekto tiel komencis esti kunmetita en 1 minuto anstataŭ 5 minutoj).
Ĉio ĉi, kompreneble, havas sencon nur se vi havas vian propran internan CI/KD-servilon, kiun vi subtenas mem. Sed nun ekzistas multaj nubaj servoj, en kiuj ĉiuj ĉi tiuj problemoj estas solvitaj kaj vi ne devas zorgi pri tio, kaj la necesaj asembleaj propraĵoj ankaŭ povas esti specifitaj en la projektaj agordoj.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi tenas vian CI/KD-sistemon interne aŭ uzas trian servon?
-
Ni uzas internan servilon
-
Ni uzas eksteran servon
-
Ni ne uzas CI/CD
-
Aliaj
42 uzantoj voĉdonis. 16 uzantoj sindetenis.
fonto: www.habr.com