Bou 'n Android-projek in 'n Docker-houer

Wanneer jy 'n projek vir die Android-platform ontwikkel, selfs die kleinste een, moet jy vroeër of later die ontwikkelingsomgewing hanteer. Benewens die Android SDK, is dit nodig om die nuutste weergawe van Kotlin, Gradle, platform-tools, build-tools te hê. En as al hierdie afhanklikhede op die ontwikkelaar se masjien in 'n groter mate opgelos word deur die Android Studio IDE te gebruik, kan elke opdatering op die CI/CD-bediener 'n kopseer word. En as Docker in webontwikkeling die standaardoplossing vir die omgewingsprobleem geword het, hoekom probeer dan nie om 'n soortgelyke probleem in Android-ontwikkeling op te los deur dit te gebruik nie ...

Vir diegene wat nie weet wat Docker is nie, om dit eenvoudig te stel, is dit 'n hulpmiddel om die sogenaamde. "houers" wat 'n minimale OS-kern en die nodige stel sagteware bevat wat ons kan ontplooi waar ons wil, terwyl ons die omgewing bewaar. Wat presies in ons houer sal wees, word bepaal in die Dockerfile, wat dan saamgestel word in 'n prent wat enige plek bekendgestel kan word en het idempotensie-eienskappe.

Die installasieproses en basiese beginsels van Docker word perfek beskryf in syne amptelike webwerf. Daarom, as ons 'n bietjie vorentoe kyk, is dit die Dockerfile waarmee ons geëindig het:

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

Ons stoor dit in die gids met ons Android-projek en begin die houer bou met die opdrag

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

Parameter -t spesifiseer die merker of naam van ons houer, wat gewoonlik uit sy naam en weergawe bestaan. In ons geval het ons dit android-build genoem en in die weergawe het ons 'n stel weergawes van gradle, android-sdk en platform-tools aangedui. In die toekoms sal dit vir ons makliker wees om met behulp van hierdie "weergawe" na die prent wat ons benodig by die naam te soek.

Nadat die samestelling voltooi is, kan ons ons beeld plaaslik gebruik, ons kan dit aflaai met die opdrag docker druk na 'n publieke of private beeldbewaarplek om dit na ander masjiene af te laai.

As voorbeeld, kom ons bou 'n projek plaaslik. Om dit te doen, voer die opdrag in die gids met die projek uit

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

Kom ons vind uit wat dit beteken:

docker run - die beeld bekendstelling opdrag self
-rm — beteken dat nadat die houer gestop het, dit alles uitvee wat gedurende sy lewe geskep is
-v "$PWD":/home/gradle/ - monteer die huidige vouer met ons Android-projek in die interne houer-lêergids /home/gradle/
-w /huis/gradle - spesifiseer die werksgids van die houer
Android-bou: 5.4.1-28-27 — die naam van ons houer wat ons versamel het
gradle assembleDebug — die werklike monteerspan wat ons projek saamstel

As alles goed gaan, sal jy binne 'n paar sekondes/minute iets soos op jou skerm sien BOU SUKSESVOL in 8m 3s! En die app/build/output/apk-lêergids sal die saamgestelde toepassing bevat.

Jy kan ander graad take op 'n soortgelyke manier uitvoer - kontroleer die projek, voer toetse uit, ens. Die grootste voordeel is dat as ons die projek op enige ander masjien moet bou, ons nie hoef te bekommer oor die installering van die hele omgewing nie en dit sal genoeg wees om die nodige prent af te laai en die bou daarin uit te voer.

Die houer stoor geen veranderinge nie, en elke samestelling word van nuuts af geloods, wat aan die een kant die identiteit van die samestelling waarborg, ongeag waar dit geloods word, aan die ander kant, elke keer as u al die afhanklikhede moet aflaai en stel al die kode weer saam, en dit kan soms aansienlike tyd neem. Daarom, bykomend tot die gewone "koue" begin, het ons die opsie om die bou te begin terwyl ons die sg. "cache", waar ons die ~/.gradle-lêergids stoor deur dit eenvoudig na die projek se werklêer te kopieer, en aan die begin van die volgende bouwerk stuur ons dit terug. Ons het alle kopieerprosedures in aparte skrifte geskuif en die bekendstellingsbevel self het so begin lyk

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"

As gevolg hiervan is ons gemiddelde projekboutyd verskeie kere verminder (afhangende van die aantal afhanklikhede van die projek, maar die gemiddelde projek het dus in 1 minuut in plaas van 5 minute begin saamgestel word).

Dit alles maak natuurlik net sin as jy jou eie interne CI/CD-bediener het, wat jy self ondersteun. Maar nou is daar baie wolkdienste waarin al hierdie probleme opgelos is en jy hoef nie daaroor bekommerd te wees nie, en die nodige samestellingseienskappe kan ook in die projekinstellings gespesifiseer word.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Hou jy jou CI/CD-stelsel in die huis of gebruik jy 'n derdepartydiens?

• Ons gebruik 'n interne bediener

• Ons gebruik 'n eksterne diens

• Ons gebruik nie CI/CD nie

• Ander

42 gebruikers het gestem. 16 gebruikers het buite stemming gebly.

Bron: will.com