Bij het ontwikkelen van een project voor het Android-platform, hoe klein ook, krijg je vroeg of laat te maken met de ontwikkelomgeving. Naast de Android SDK is het noodzakelijk om de nieuwste versie van Kotlin, Gradle, platform-tools, build-tools te hebben. En als op de machine van de ontwikkelaar al deze afhankelijkheden in grotere mate worden opgelost met behulp van de Android Studio IDE, dan kan op de CI / CD-server elke update hoofdpijn worden. En als Docker in webontwikkeling de standaardoplossing is geworden voor het milieuprobleem, waarom probeert u er dan niet een soortgelijk probleem mee op te lossen in Android-ontwikkeling ...
Voor degenen die niet weten wat Docker is - als het vrij eenvoudig is, dan is dit een hulpmiddel voor het maken van de zogenaamde. "Containers" die de minimale OS-kernel bevatten en de benodigde set software die we kunnen implementeren waar we maar willen, met behoud van de omgeving. Wat er precies in onze container zal zitten, wordt bepaald in de Dockerfile, die vervolgens wordt samengesteld tot een afbeelding die overal kan worden gestart en idempotentie-eigenschappen heeft.
Het installatieproces en de basisprincipes van Docker staan ββprachtig beschreven op zijn
# Π’.ΠΊ. ΠΎΡΠ½ΠΎΠ²Π½ΡΠΌ ΠΈΠ½ΡΡΡΡΠΌΠ΅Π½ΡΠΎΠΌ Π΄Π»Ρ ΡΠ±ΠΎΡΠΊΠΈ 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"
We slaan het op in de map met ons Android-project en beginnen met het bouwen van de container met de opdracht
docker build -t android-build:5.4-28-27 .
Parameter -t stelt de tag of naam van onze container in, die meestal bestaat uit de naam en versie. In ons geval noemden we het android-build en in de versie specificeerden we een combinatie van gradle-, android-sdk- en platform-tools-versies. In de toekomst zullen we met zo'n "versie" gemakkelijker op naam kunnen zoeken naar de afbeelding die we nodig hebben.
Nadat de build is voltooid, kunnen we onze afbeelding lokaal gebruiken, we kunnen deze downloaden met de opdracht docker push naar een openbare of privΓ©-afbeeldingsopslagplaats om deze naar andere machines te downloaden.
Laten we als voorbeeld een lokaal project bouwen. Voer hiervoor de opdracht uit in de projectmap
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug
Laten we uitzoeken wat het betekent:
koppelingsrun - de opdracht voor het starten van afbeeldingen zelf
-rm - betekent dat na het stoppen van de container alles wordt verwijderd dat tijdens zijn leven is gemaakt
-v "$PWD":/home/gradle/ - koppelt de huidige map met ons Android-project aan de interne map van de container /home/gradle/
-w /home/graad - stelt de werkmap van de container in
Android-build: 5.4.1-28-27 - de naam van onze container die we hebben opgehaald
graduele assembleDebug - het bouwteam zelf, dat ons project in elkaar zet
Als alles goed gaat, zie je na een paar seconden / minuten zoiets als SUCCESVOL BOUWEN in 8m 3s! En in de map app/build/output/apk staat een samengestelde applicatie.
Op dezelfde manier kunt u andere geleidelijke taken uitvoeren - het project controleren, tests uitvoeren, enz. Het belangrijkste voordeel is dat als we het project op een andere machine moeten bouwen, we ons geen zorgen hoeven te maken over het installeren van de hele omgeving, en dat het voldoende is om de benodigde afbeelding te downloaden en de build erop uit te voeren.
De container slaat geen wijzigingen op en elke assembly wordt vanaf nul gestart, wat aan de ene kant de identiteit van de assembly garandeert, ongeacht waar deze wordt gestart, aan de andere kant elke keer dat u alle afhankelijkheden moet downloaden en compileer alle code opnieuw, en dit kan soms veel tijd kosten. Daarom hebben we naast de gebruikelijke "koude" start de mogelijkheid om de montage te starten met behoud van de zgn. "cache", waar we de map ~/.gradle opslaan door deze simpelweg naar de werkmap van het project te kopiΓ«ren, en aan het begin van de volgende build geven we deze terug. We hebben alle kopieerprocedures in afzonderlijke scripts ondergebracht en het startcommando zelf begon er zo uit te zien
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"
Als gevolg hiervan werd de gemiddelde bouwtijd van een project meerdere keren verkort (afhankelijk van het aantal afhankelijkheden van het project, maar begon het gemiddelde project dus te bouwen in 1 minuut in plaats van 5 minuten).
Dit alles op zich heeft alleen zin als u een eigen interne CI / CD-server heeft, die u zelf ondersteunt. Maar nu zijn er veel cloudservices waarin al deze problemen zijn opgelost en je er geen omkijken naar hebt, en ook de benodigde build-eigenschappen kunnen worden opgegeven in de projectinstellingen.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek.
Houdt u uw CI/CD-systeem intern of gebruikt u een service van derden
-
Een interne server gebruiken
-
Een externe dienst gebruiken
-
We gebruiken geen CI/CD
-
Ander
42 gebruikers hebben gestemd. 16 gebruikers onthielden zich van stemming.
Bron: www.habr.com