- Azure
- Azure DevOps
Lorsque vous développez une application mobile, vous devez livrer un apk régulièrement, par exemple lorsque vous souhaitez mettre à jour votre application sur le Google Play Store.
Pour ce faire, vous devez suivre quelques étapes:
Bien sûr, vous pouvez faire toutes ces étapes manuellement mais :
L’idée est d’automatiser ce process en utilisant un très bon outil: Azure DevOps, ce processus est appelé intégration continue.
L’intérêt d’utiliser Azure DevOps réside dans le fait que :
Nous allons créer quelque chose appelé un pipeline qui vous permettra de générer votre apk en un seul clic. Pour ce faire, nous utiliserons les Azure Pipelines.
Allez dans Azure DevOps et dans la section Pipelines et Builds/Pipelines, créez un nouveau projet, puis suivez les 4 étapes pour obtenir le code source à partir du repository approprié:
Azure DevOps créera automatiquement un nouveau fichier à la racine du dossier de votre projet appelé azure-pipelines.yml
. Vous devrez valider ce fichier dans votre référentiel de code.
Il contient la définition du job de votre projet définie en yaml
, il sera interprété par Azure DevOps pour savoir comment créer et signer votre application.
Ce qui est intéressant avec ce type de définition de job c’est:
azure-pipelines.yml
yaml
est facile à lire et à maintenirAccédez à votre projet Azure DevOps et modifiez le pipeline. Le fichier azure-pipelines.yml
s’ouvrira et, au-dessus, vous verrez les lignes suivantes:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
Comme vous pouvez le constater, chaque fois que quelque chose est poussé sur la branche * master , un nouveau build est lancé sur une machine virtuelle dotée de la dernière version d’Ubuntu*.
Changeons la vmImage pour une version de Mac, cela fixera un problem de chemin d’accès pour l’outil zipalign :
pool:
vmImage: 'macOS-10.13'
Ensuite, nous devons créer nos différentes tâches sous la définition de steps
pour définir ou créer un pipeline.
Pour construire un projet Android, la bonne pratique consiste maintenant à utiliser Gradle
, ajoutons donc cette tâche:
- task: Gradle@2
inputs:
workingDirectory: ''
gradleWrapperFile: 'gradlew'
gradleOptions: '-Xmx3072m'
javaHomeOption: 'JDKVersion'
jdkVersionOption: '1.8'
jdkArchitectureOption: 'x64'
publishJUnitResults: false
testResultsFiles: '**/TEST-*.xml'
tasks: 'assembleRelease'
Pour le paramètre tasks, je choisis assembleRelease car je souhaite builder le mode Release par défaut. N’hésitez pas à définir la configuration de Gradle appropriée en fonction des besoins de votre projet. Maintenant, si vous lancez le job, vous devriez avoir tout réussi:
Il est maintenant temps de signer notre application que nous venons de builder à l’aide du keystore. N’oubliez pas que sans signer l’application, vous ne pourrez pas l’installer sur un appareil n’y l’uploader sur le store.
En dessous de la tâche de build Gradle, ajouter une nouvelle tâche pour signer l’application Android :
Pour les besoins du tutoriel, les données du keystore sont visibles, mais vous devez utiliser les variables secrètes à la place recommandée par Microsoft. Si vous n’êtes pas familier avec cela, vous pouvez consulter mon tutoriel à ce sujet.
- task: AndroidSigning@3
inputs:
apkFiles: '**/*.apk'
apksign: true
apksignerKeystoreFile: 'production.keystore'
apksignerKeystorePassword: 'keystorepwd'
apksignerKeystoreAlias: 'key0'
apksignerKeyPassword: 'aliaspwd'
apksignerArguments: --out $(Build.SourcesDirectory)/app/build/outputs/apk/release/ my-crazy-app.release.apk
zipalign: true
Je vous recommande de spécifier le apksignerArguments
comme je l’ai fait pour donner un nouveau nom à l’apk signé. Si vous ne le faites pas, l’apk signé aura le même nom que celui non signé. Si vous mettez le job en file d’attente maintenant, vous obtiendrez cette erreur:
Cette erreur vous indique que le fichier de clés n’est pas trouvé car le pipeline n’y a pas accès. Pour résoudre ce problème, accédez à la section Pipelines et Library puis, dans l’onglet Fichiers sécurisés, où vous devez uploader votre keystore:
Revenez ensuite au dernier job ayant échoué et cliquez sur le bouton Authorize resources pour pouvoir l’utiliser sans erreur. Vous pouvez maintenant relancer le build sans erreur.
Nous avons notre apk buildé et signé, il est temps d’obtenir l’apk généré sur notre machine. Nous devons d’abord copier l’apk dans les répertoires des artéfacts avec une première task. Notez que je choisis tous les fichiers apk qui se terminent par .release.apk
comme défini précédemment dans la task de signature Android.
- task: CopyFiles@2
inputs:
SourceFolder: $(Build.SourcesDirectory)
contents: '**/*.release.apk'
targetFolder: '$(build.artifactStagingDirectory)'
overWrite: true
Dernière étape, nous publions les artéfacts afin qu’ils puissent être téléchargés en cliquant sur le bouton Artifacts.
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)/app/build/outputs/apk/release/'
artifactName: 'apks'
publishLocation: 'container'
Si tout se passe bien, vous verrez quelque chose comme ceci:
Sources:
Vous trouverez un exemple de code sur ce répertoire Github.
Happy codding !
Vous avez aimé ce tutoriel ? Laissez une étoile sur le répertoire Github associé !