• Non classé
  • 3

Intégration Continue pour Android

On nous demande souvent si notre projet possède une intégration continue, euh… on va dire oui… mais qu’est-ce que c’est réellement ? Je vais dans cette suite de tutoriels vous montrer en quoi consiste cette plateforme, et quels sont les pluvalues pour le projet, et surtout pourquoi les clients sont fans de cette idée !

Wiki

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.

Vous l’aurez bien compris, on va mettre en place des logiciels qui vont nous aider au cours de notre développement,
que ce soit pour automatiser des taches, mais aussi détecter des erreurs sur notre application.

Cycle d’intégration pour Android

Je vais ici vous donner un cycle d’intégration possible (il existe une multitude de logiciels, plus ou moins payant 😛 )

Je ne vais ici que présenter les logiciel, vous trouverez pour chacun un article dédié à sa mise en place et à son utilisation

1. Automatiser nos taches avec Jenkins 

Jenkins est un ordonnanceur, c’est à dire que nous pouvons définir des taches (ex: scripts shell) à exécuter à des moments donnés, par exemple suite à un push sur git, ou à une heure précise de la journée.

Je pourrai ainsi essayer de compiler mon projet et exécuter les tests unitaires dessus tous les jours à 12h00 par exemple.

Ce sera le point central de l’intégration continue, nous allons créer plusieurs job pour chaque action que nous voulons effectuer :

  • Compilation et tests unitaires
  • Analyse du code et tests d’interface graphique
  • Déploiement beta
  • Déploiement sur le play store

2. Mise en place d’un système de Pull Request avec Gihub 

Nous allons choisir d’héberger notre code sur un repo GIT acceptant le système de Pull Request : Github. C’est à dire que chaque dévelopeur devra travailler sur sa propre branche et proposer une Pull Request (demande de fusion) afin que son code soit disponible sur la branche « commune » (souvent la branche develop).

Ainsi, notre travail n’interfère pas avec celui des autres développeurs, puis il est nécessaire que le reste de l’équipe relise le code qu’il a produit afin de le valider, pour enfin le fusionner avec la branche commune.

3. Analyse du code avec Sonar 

Afin de rassurer le client sur la qualité du code produit, il existe des outils d’analyse de code, qui donneront une « note » à notre projet. Sonar est l’un des plus connu, il va analyser les potentielles erreurs Java de notre projet (ex: NullPointer possibles, erreurs de cast…) mais aussi des améliorations possibles (suppression de code redondant, attributs pouvant être statiques…).

Il va fournir un rapport détaillé comprenant une note sur le projet ainsi qu’un nombre de jours de dette technique, le pourcentage de code couvert par des tests unitaires, etc. Vous pourrez comme cela fidéliser votre client, ces données sont parlantes pour lui 😉

4. Tests automatisés d’interface graphique avec Espresso

Après avoir modifié du code, vous devez être sure que cela n’a pas cassé le comportement de votre application. Pour cela il vous faut définir des comportements d’utilisateurs (par exemple : authentification, puis click sur un article, puis click sur partager) à automatiser.

Pour cela je vous conseille d’essayer Espresso (de google), et de lancer job Jenkins chaque nuit, qui va lancer un émulateur, puis exécuter vos tests UI. Vous pourrez aussi exécuter des screenshots et récupérer un rapport en utilisant Spoon.

5. Rapports de crash avec Crashlytics

Une fois votre application déployée sur le play store (ou autre), il est difficile de récupérer les rapports de crash. Google Play Store ne vous remonte que les ANR, mais pas tous les crash.

Je vous conseille d’installer Crashlytics, Il vous permettra de connaitre l’ensemble des crash reçus par les utilisateurs, et vous fournira de même un pourcentage de crash free users, c’est à dire le nombre d’utilisateurs n’ayant pas d’erreurs en utilisant votre application, information précieuse pour votre client 😉

6. Distribution beta avec Fabric 

Vous avez besoin d’envoyer un apk à votre client avant de le distribuer sur le play store ? ou à un pannel de testeurs ?

Essayez Beta de Fabric, il est facilement utilisable depuis Jenkins, créer un job du genre « Deploy beta » relié à la branche commune, puis lorsque vous l’exécuterez, le client recevra le nouvel APK (qui aura passé tous les tests unitaires, etc.) sur son téléphone de test.

7. Publication automatisée de l’apk sur le Play Store

Dernière étape, la publication sur le play store de notre application. Il est possible de l’automatiser, et de la restreindre au fait que les tests d’interface sont au vert, ainsi que les tests unitaires.

Pour cela je vous conseille de regarder la documentation officielle de google à ce sujet.

Schéma d’intégration continue

Voici un schéma récapitulatif de quelques fonctionnalités que nous pouvons effectuer via notre cycle d’intégration continue :

Conclusion

Vous savez maintenant ce qu’est un cycle d’intégration continue, il ne reste plus qu’à le mettre en place !

Gardez toujours en tête que l’automatisation de ces taches est certe une plus-value pour fiabiliser votre client, mais vous fera aussi gagner du temps dans l’élaboration de votre projet 🙂

Je vous donne donc rendez-vous dans notre article dédié à la mise en place de Jenkins pour Android !

 

 

Vous aimerez aussi...

3 réponses

  1. Oussama dit :

    Un très bon article, merci Florent ! J’attends le prochain article avec impatience

  2. ayoub dit :

    Great article !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *