ProHoster > блог > Администрација > Изградба на проект за Android во контејнер Docker

Изградба на проект за Android во контејнер Docker

Кога развивате проект за Android платформата, дури и за најмал, порано или подоцна треба да се справите со развојната средина. Покрај Android SDK, неопходно е да се има најновата верзија на Kotlin, Gradle, платформа-алатки, build-tools. И ако на машината на развивачот сите овие зависности се решат во поголема мера со користење на Android Studio IDE, тогаш на серверот CI/CD секое ажурирање може да се претвори во главоболка. И ако во веб-развојот Docker стана стандардно решение за проблемот со животната средина, тогаш зошто да не се обидете да решите сличен проблем во развојот на Android користејќи го ...

За оние кои не знаат што е Docker, едноставно кажано, тоа е алатка за создавање на т.н. „Контејнери“ кои содржат минимално јадро на ОС и потребниот сет на софтвер што можеме да го распоредиме каде сакаме, притоа зачувувајќи ја околината. Што точно ќе биде во нашиот контејнер е одредено во Dockerfile, кое потоа се составува во слика што може да се лансира насекаде и има својства на идемпотенција.

Процесот на инсталација и основите на Docker се совршено опишани во неговиот официјална веб-страница. Затоа, гледајќи малку напред, ова е 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"

Го зачувуваме во папката со нашиот Андроид проект и започнуваме да го градиме контејнерот со командата

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

Параметар -t ја одредува ознаката или името на нашиот контејнер, кој обично се состои од неговото име и верзија. Во нашиот случај, го нарековме Android-build и во верзијата посочивме сет на верзии на gradle, android-sdk и платформа-алатки. Во иднина, ќе ни биде полесно да ја бараме сликата што ни треба по име користејќи ја оваа „верзија“.

Откако ќе заврши склопувањето, можеме да ја користиме нашата слика локално, можеме да ја преземеме со командата докер туркање во јавно или приватно складиште за слики за да го преземете на други машини.

Како пример, ајде да изградиме проект локално. За да го направите ова, во папката со проектот, извршете ја командата

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

Ајде да разбереме што значи тоа:

докерски трчаат - самата команда за лансирање на сликата
-рм — значи дека откако ќе застане контејнерот, брише се што е создадено за време на неговиот животен век
-v „$PWD“:/home/gradle/ — ја монтира тековната папка со нашиот Андроид проект во внатрешната папка на контејнер /home/gradle/
-w /home/gradle — го одредува работниот директориум на контејнерот
андроид-изградба: 5.4.1-28-27 — името на нашиот контејнер што го собравме
gradle assembleDebug — вистинскиот тим за склопување кој го составува нашиот проект

Ако сè оди добро, тогаш за неколку секунди/минути ќе видите на вашиот екран нешто слично ГРАДЕТЕ УСПЕШНО за 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 корисници беа воздржани.

Извор: www.habr.com

Додадете коментар