photo d'Unsplash pour "pipeline"
Approche générale
Salut Je commence une série de publications sur les pipelines en développement et pas seulement qui aident à vérifier la qualité des applications mobiles en cours de développement. L'idée principale est de mettre en évidence toutes les approches du développement mobile qui sont pertinentes aujourd'hui: le développement natif pour Android et iOS, React Native, Xamarin et Flutter. Je vais commencer avec Android, mais je voudrais d'abord donner une idée générale de ce dont il s'agit.
Gardez à l'esprit qu'il s'agit d'un aperçu général des outils et des pratiques qui peuvent être utiles lors du développement d'applications Android, et non d'un didacticiel sur la façon de configurer ces outils.
À quoi ça sert?
Commençons par la vérité bien connue: plus tard vous trouvez un défaut dans l'application, plus il est coûteux de le réparer. Supposons que vous ayez découvert un bogue déjà en production. Vos testeurs doivent reproduire ce bogue localement, l'enregistrer, le prioriser, le transmettre aux développeurs, et ils doivent à leur tour le corriger, créer un nouvel assemblage, le renvoyer aux testeurs afin qu'ils soient convaincus que tout est corrigé, puis effectuer la génération de la version, et alors seulement envoyez la nouvelle version aux utilisateurs.
De nombreuses heures de travail pourraient être économisées si vous disposiez de mécanismes pour empêcher l'apparition de bogues au tout début. Je ne dis pas qu'il existe une solution miracle qui élimine tous les bugs - c'est impossible. Mais ce qui est possible est d'ériger des barrières (également appelées portes de qualité) qui augmentent la probabilité d'attraper des bogues dans votre code le plus tôt possible.
Sur l'ordinateur du développeur
En tant que développeur, vous travaillez toujours sur votre machine avec un IDE et des outils de ligne de commande. Voyons ce qui existe pour les développeurs Android.
Android Studio
C'est maintenant l'option par défaut pour le développeur Android, et comme elle est basée sur la plate-forme IntelliJ, il existe de nombreuses inspections pour Java, Kotlin et XML. Je vous conseille de vous mettre d'accord au sein d'une équipe sur les règles spécifiques que vous souhaitez utiliser, de les configurer sur un ordinateur et de télécharger le fichier settings.jar avec ces règles dans votre système de contrôle de version ou une sorte d'outil de travail collaboratif (comme Confluence).
Paramètres d'inspection dans Android Studio
AS propose également des correctifs rapides qui peuvent être appliqués à votre code en appuyant sur Alt + Entrée.
Exemple de solution rapide d'Android Studio
Android Lint
Il s'agit d'un outil d'analyse statique spécifiquement pour le développement Android, prêt à l'emploi avec des centaines de règles, que vous pouvez utiliser. Lint peut également être lancé à partir de la tâche Gradle (tâche), donner des invites directement dans Android Studio et générer un rapport. Il comporte de nombreux contrôles, répartis en catégories - sécurité, internationalisation, convivialité, performances ...
Mais la possibilité d'ajouter vos propres règles le rend particulièrement puissant. Par exemple, Room a son propre ensemble de règles, la bibliothèque de journalisation Timber a la sienne. Vous pouvez créer des règles pour votre équipe ou votre projet et être sûr que personne ne fait certaines erreurs typiques. (Soit dit en passant, bientôt à la conférence Mobius, il y aura un rapport à ce sujet, expliquant à la fois le côté théorique et le côté pratique).
Exemple de rapport Android Lint
Analyse plus statique
Bien sûr, il existe de nombreux outils d'analyse statique conçus non spécifiquement pour Android, mais en général pour Java et Kotlin : PMD , FindBugs (abandonnés, utilisez SpotBugs ), Checkstyle , Ktlink , Detekt et autres. Choisissez à votre guise, intégrez-le dans votre pipeline et assurez-vous de son utilisation réelle (comment exactement? Lire la suite).
Exemple de rapport de FindBugs
Mais il ne suffit pas d'avoir un outil qui fournit des données sur ce qui doit être corrigé. Vous trouverez également les informations suivantes utiles:
- Comment la couverture du code avec les tests change-t-elle au fil du temps?
- Combien de temps me faudra-t-il pour résoudre tous les problèmes rencontrés?
- Combien de code en double y a-t-il dans le projet?
- Comment étendre mes règles à plusieurs équipes?
Et bien d'autres. Chez EPAM Systems, nous nous concentrons sur la qualité, nous avons donc choisi SonarQube comme outil pour répondre à ces questions. Pour d'autres avantages SonarQube, cliquez ici .
Tests unitaires
J'espère que vous n'aurez pas à vous rassurer à nouveau sur le fait que votre fichu code a besoin de tests unitaires pour diverses raisons . Peu importe si vous suivez le TDD, adhérez au principe de la pyramide de test ou à la nouvelle idée du champignon de test . Peu importe le niveau de couverture que vous définissez comme objectif, en tout cas, vos tests unitaires sont une composante nécessaire. Donc, vous devez les écrire et les exécuter! Heureusement, sur 11 ans d'évolution, nous avons obtenu un mécanisme assez pratique pour exécuter des tests à partir du plug-in Gradle et Android Gradle.
Dans le projet Android, le projet par défaut a une tâche testDebugUnitTest (pour vous, bien sûr, elle peut différer selon les saveurs), et c'est elle qui exécute les tests. Assurez-vous de l'utiliser et que la couverture du code augmente avec le temps. L'avantage des tests unitaires Java est qu'ils fonctionnent sur la station de travail JVM, et non sur Dalvik / ART, ce qui donne un avantage de vitesse.
Dans le cas des tests unitaires Android, il y a un problème fondamental: la dépendance à l'égard du SDK Android. C'est l'une des raisons pour lesquelles toutes ces approches de la couche d'interface utilisateur sont apparues comme MVP, MVVM, MVI et autres MV *. Le problème spécifique en fonction de la classe sur Android est que les tests unitaires tombent simplement en raison de l'utilisation de talons de cet Android lui-même, ce qui lève simplement une exception. Bien sûr, il existe deux options: soit ignorer les tests pour cette classe, soit extraire une partie de la logique dans d'autres classes, ou créer des interfaces pour les classes dépendant d'Android pour tester une logique de haut niveau, ou utiliser Robolectric (ce qui est loin d'être idéal). Une autre option consiste à utiliser des tests instrumentés, qui peuvent convenir pour vérifier le comportement d'une activité, mais la tendance actuelle est que l'activité ne devrait pas contenir de tests.
À la question de la couverture: vous voulez savoir ce que c'est à votre moment et comment cela change au fil du temps, de sorte que vous auriez également besoin d'un outil pour cela. Pour autant que je sache, jacoco est un standard de l'industrie pour Java, et il a un support Kotlin.
Tests instrumentés
Ces tests s'exécutent sur l'émulateur Android, ce qui leur permet d'utiliser le framework Android. Malheureusement, ils sont lents et instables (en raison de certains problèmes avec l'émulateur), donc la plupart des développeurs que je connais personnellement essaient de les éviter. Mais leur support est dans Gradle et Android Studio, donc pour vous, ils peuvent convenir.
Audit de sécurité
Outre les erreurs simples, les fautes de frappe, les problèmes de copier-coller et autres, il existe également une grande catégorie de problèmes auxquels vous devez faire attention: la sécurité. Bien sûr, Android Lint fournit déjà quelques conseils pertinents, mais il est préférable de prendre soin d'outils spécialisés spécifiquement pour cette tâche. Ces outils peuvent fonctionner en modes statique et dynamique; selon vos exigences de sécurité, vous pouvez utiliser l'un de ces modes, ou les deux. Vous voudrez peut-être commencer, par exemple, avec Mobile Security Framework , puis envisager des options payantes.
Heureusement, il existe une liste d' outils d'analyse statique compilés directement par OWASP. Par exemple, vous pouvez choisir Rechercher des bogues de sécurité ou utiliser le projet OWASP SonarCube .
Vérifier les vérifications
Comme je l'ai dit, plus le cycle de rétroaction est court, moins vous consacrez de temps et d'argent à la correction des bogues. Je veux donc être sûr que le code correspond à la qualité de production avant même qu'il n'atteigne le référentiel ou même communique localement. Bien sûr, vous pouvez simplement demander à vos développeurs d'effectuer des vérifications, mais il existe une bien meilleure option: les hooks Git.
Je suggère d'ajouter un crochet de pré-validation pour toutes les vérifications dont nous avons discuté ci-dessus: Lint, analyse de code statique et tests unitaires. Un exemple du processus d'installation peut être trouvé ici .
Pipeline CI / CD
Il est très difficile d'imaginer un projet Android sans pipeline CI / CD. Votre objectif est de répéter toutes les vérifications ci-dessus au stade de l'assemblage. Il y a plusieurs raisons à cela:
- Les crochets Git peuvent être facilement contournés avec l'option --no-verify
- Le code peut réussir toutes les vérifications localement, mais introduire des problèmes après la fusion
- Besoin de rapports de test et de couverture
Exemple de rapport sur bitrise.io
Heureusement, il vous suffit de mentionner ces vérifications de sécurité directement dans le script de génération Gradle ou d'appeler les tâches correspondantes dans votre pipeline CI / CD. Si vous avez des difficultés à construire un pipeline, j'ai récemment fait une présentation lors de la conférence DevOops sur les DevOps mobiles en 2019.
Veuillez également procéder comme suit:
- Exécutez toutes les vérifications des demandes d'extraction. Ne laissez pas fusionner une demande qui viole l'une des règles. C'est très important: si la règle n'est pas exécutée, alors, en fait, elle n'existe pas.
- Exécutez toutes les vérifications pendant l'assemblage et le déploiement. Vous ne voulez pas abaisser votre barre de qualité.
- Si la construction est cassée, c'est la première priorité. L'équipe doit résoudre le problème immédiatement, car cela viole votre pratique de livraison continue et empêche l'équipe d'écrire un code de qualité.
Et bonne chance pour améliorer votre code!
Si vous avez aimé cet article, suivez-moi sur Twitter pour ne pas manquer ce qui suit. Et si vous serez à Moscou en décembre ou si vous pouvez venir, venez à notre conférence Mobius et découvrez beaucoup d'autres choses sur le développement pour Android (et iOS)!
PS Merci à vixentael d' avoir abordé les problèmes de sécurité, à Alexei Nikitin pour la révision et les commentaires, à Alexander Bakanov pour la relecture.