• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 02/02/2022

Améliorez la qualité de votre code

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Votre mini-application SaveMyTrip est maintenant terminée, et vous en êtes vraiment très satisfait. Tellement que vous l'avez lancée récemment sur le Play Store... et elle cartonne ! :soleil: Vous avez d'ailleurs même dû embaucher plusieurs développeurs afin de la maintenir et de la faire évoluer.

Franchement, je suis trop content ! Bon par contre, travailler en équipe, ce n'est pas facile... surtout qu'il faut que je vérifie constamment que mes collaborateurs ne cassent pas tout le code qui a déjà été créé ! :euh:

Ah ! Eh bien, cela peut être facilement évité, notamment grâce à l'intégration continue ! :)

Je n'ai absolument aucune idée de ce dont tu me parles...

Oui j'en ai bien l'impression… ;) Eh bien, voici la définition de Wikipédia, qui résume bien ce concept :

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée. 

Le principal but de cette pratique est de détecter les problèmes d'intégration au plus tôt lors du développement. De plus, elle permet d'automatiser l'exécution des suites de tests et de voir l'évolution du développement du logiciel.

En fait, actuellement, vous avez déjà créé quelques tests qui "protègent" d'une certaine façon votre code et qui vous permettent d'être relativement serein sur la suite de votre développement. Cependant, quand vous travaillez en équipe, une erreur est vite arrivée : un développeur qui modifie une fonctionnalité et qui n'exécute pas les tests, puis qui publie en production votre application... et là, c'est le drame ! Une régression survient, chose que vous auriez pu éviter si les tests avaient été lancés en amont, de manière automatisée.

Grâce à l'intégration continue, vous allez justement pouvoir automatiser ce processus assez facilement... ;) Ainsi, dans ce dernier chapitre, je vais vous montrer comment automatiser le lancement de vos tests grâce à Github Action.

Déposez votre projet sur Github

Pour commencer, inscrivez-vous à Github (si ce n’est pas déjà fait) et déposez votre projet en créant un nouveau repository.

Paramétrez l’intégration continue

Tout d’abord, allez dans votre projet Github et cliquez sur l’onglet Action :

Dans le projet Github, le bouton action est encadré pour indiquer qu'il faut cliquer dessus

Cliquez sur “Set up this workflow” pour que la magie opère.

Dans le projet Github, on trouve le bouton Set up this workflow Un fichier yml va se générer tout seul avec le strict nécessaire pour récupérer le projet, le builder et le pousser sur Github.

Voici à quoi il ressemble :

# This workflow will build a package using Gradle and then publish it to GitHub packages when a release is created
# For more information see: https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#Publishing-using-gradle
name: Gradle Package
on:
release:
types: [created]
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
server-id: github # Value of the distributionManagement/repository/id field of the pom.xml
settings-path: ${{ github.workspace }} # location for the settings.xml file
- name: Build with Gradle
run: gradle build
# The USERNAME and TOKEN need to correspond to the credentials environment variables used in
# the publishing section of your build.gradle
- name: Publish to GitHub Packages
run: gradle publish
env:
USERNAME: ${{ github.actor }}
TOKEN: ${{ secrets.GITHUB_TOKEN }}

Automatisez l'exécution des tests avec l'intégration continue

Nous allons maintenant modifier ce code pour qu’à chaque pull request, nos tests s’exécutent. Pour cela, nous allons modifier la propriété “on” pour lui demander d’écouter des pull_request et non des releases :

on:
pull_request:
branches:
- master
- starter

Ok… mais que veut dire ce code exactement 🧐 ?!

Ici, on demande d’écouter chaque ouverture de pull request voulant être mergée sur la branche master ou starter.

Maintenant, demandons-lui de démarrer les tests. Dans notre projet, nos tests sont dans le répertoire androidTest car ils doivent être  exécutés sur un smartphone.

Pour cela, nous pouvons aller dans la marketplace de Github Action pour chercher une extension pouvant faire cela.

Bingo ! Il en existe une :

Une recherche à la main fait apparaître l'extension Android Emulator Runner 

En cliquant sur cette extension, vous pourrez voir toute sa documentation.

Je suis sympa, je vous donne la configuration pour notre projet à ajouter dans notre fichier yml, juste avant l’action “Publish to Github Package” :

- name: Android Emulator Runner
# You may pin to the exact commit or the version.
# uses: ReactiveCircus/android-emulator-runner@2b2ebf2e518e38a17180117fc2b677006db27330
uses: ReactiveCircus/android-emulator-runner@v2.21.0
with:
api-level: 23
target: default
arch: x86
profile: Nexus 6
script: ./gradlew connectedCheck --stacktrace
# The USERNAME and TOKEN need to correspond to the credentials environment variables used in
# the publishing section of your build.gradle
- name: Publish to GitHub Packages

Euh… on va avoir besoin d'une explication là 🤨 ! 

Ce n’est pas compliqué, ne vous inquiétez pas !

Nous lui demandons d’utiliser l’extension que nous avons trouvé avec le paramètre uses. Ensuite, nous lui donnons les paramètres du smartphone que nous voulons utiliser. Enfin, nous exécutons nos tests sur ce smartphone avec le paramètre script.

Notre fichier est enfin prêt ! Nous pouvons cliquer sur le bouton vert “Start commit” pour le sauvegarder.

 Dans l'onglet Commit New File, la case

Nous sommes enfin prêts à tester notre script !

 Testez votre intégration continue

Nous devons simplement  créer une nouvelle branche sur Github.

 New branch name : feature/test. La case Checkout branch est cochée

Faites une modification mineure pour le test, commitez et pushez sur votre branche.

Une fois que c’est fait, vous pouvez aller sur votre Github, dans l’onglet “Pull Request”, où Github va vous proposer d’ouvrir une pull request.

Génial, c’est ce qu’on voulait faire. Cliquez simplement sur le bouton “Compare & pull request”.

feature/test had recent pushes less than a munute ago s'affiche à côté du bouton Compare & Pull request

Puis, cliquez sur le bouton “Create pull request” :

Le bouton create pull request s'affiche dans l'interface

Allez dans l’onglet Action et vous verrez que notre script yml est en train de démarrer :

1 workflow run : Fix test (feature/test) Gradle Package #1: Pull request #1 opened by dsilvera, 15 seconds ago. In progress status

Vous pouvez cliquer dessus pour voir le déroulement du script :

 Fix test (Gradle Package #1). Le déroulement du script s'affiche. gradle-publis.yml on: pull_request. Build (2m15s)

Ici, si on clique sur le bouton “Build”, nous verrons en temps réel où en est l'exécution :

 Dans l'interface build, l'onglet Android Emulator Runner est déployé

Vous avez créé votre premier script d’intégration continue ! Bravo à vous !

Conclusion

Et voilà, ce cours se termine ! J'espère que vous l'aurez apprécié et surtout bien compris... :) Vous venez, sans forcément vous en rendre compte, de faire un pas de géant dans le développement sur Android ! Nous avons vu énormément de concepts assez avancés, donc prenez bien le temps de les assimiler.

Nous avons vu comment stocker des données dans les différents espaces de stockage sur Android à l'intérieur d'un fichier texte, ainsi que les exposer publiquement de manière sécurisée. Nous avons également étudié le moyen de stocker des données structurées en utilisant une base de données SQLite, grâce à la librairie Room. Et enfin, nous nous sommes penchés sur la manière d'améliorer la qualité de nos applications Android grâce à l'Architecture Components ainsi qu'à l'intégration continue.

Et comme toujours, pensez à pratiquer, pratiquer et encore pratiquer, afin que coder devienne aussi naturel que respirer... :p

D'ailleurs, une petite surprise vous attend dans le prochain chapitre : on dirait que c'est l'heure des travaux pratiques !

Exemple de certificat de réussite
Exemple de certificat de réussite