Pourquoi automatisons-nous le développement de logiciels ?

La qualité est l'un des principes que nous défendons chez Droptica. Nous voulons créer le meilleur logiciel, conformément aux exigences de nos clients - efficace, sans erreur et rentable. Dans cet article, je vais vous parler d'un des facteurs les plus cruciaux impactant la qualité du logiciel que nous développons - l'automatisation du processus de développement logiciel.

Nous sommes de fervents partisans de l'automatisation. Au cours des dix dernières années, nous avons eu de nombreuses occasions de travailler avec plusieurs clients sur divers projets et de collaborer avec des équipes variées. À chaque fois, nous avons plaidé pour le plus haut degré d'automatisation possible et pour se rapprocher autant que possible de l'Intégration Continue. Souvent, cela a permis de sauver des projets de conséquences graves.

Avant de passer aux avantages de l'automatisation, je vais vous fournir un bref résumé de son fonctionnement.

Automatisation du développement logiciel

Le processus automatisé de développement logiciel est caractérisé par les caractéristiques suivantes :

1. Un dépôt de code commun unique est mis en place. Tous les développeurs placent le code qu'ils écrivent dans le dépôt. Actuellement, Git est le système de contrôle de version le plus populaire. Le code dans le dépôt est la seule source de logiciel dans le projet. Il n'y a pas de scripts supplémentaires, de programmes ou d'autres codes envoyés par e-mail ou distribués dans l'entreprise d'une autre manière.
2. Il existe le processus dit de “build”. Le processus de build est une méthode standardisée pour créer et construire des copies successives de logiciels. Chaque développeur, testeur, script de test et mécanisme utilise exactement le même processus pour obtenir la version actuelle du logiciel.
3. Le processus de build est automatisé. Obtenir la version actuelle du logiciel ne nécessite pas qu'une personne effectue un grand nombre d'actions manuelles. Dans une situation idéale, le processus de build est un autre script ou un logiciel, qui est également versionné dans le dépôt de code. Un développeur télécharge le dernier code du dépôt, démarre le processus de build (par exemple en lançant un script) et obtient l'état actuel de l'application. Le même script doit être utilisé par tous les outils et environnements de test, ainsi que pour construire des versions de démonstration.
4. Le processus de build est rapide. La construction du paquet logiciel ne doit pas durer trop longtemps. Cela permet de tester les résultats et d'implémenter des correctifs plusieurs fois.
5. L'équipe soumet les changements souvent, chaque jour ou plusieurs fois par jour dans le meilleur des cas. Le code fonctionnel est poussé vers la branche principale du système de contrôle de version de manière continue.
6. L'environnement de test doit ressembler autant que possible à l'environnement de production . Dans une situation idéale, ce serait une copie directe de l'environnement de production.
7. Le processus de déploiement du logiciel en production est automatisé. Dans le meilleur des cas, déployer de nouveaux changements en production devrait être fait en cliquant sur un seul bouton ou en lançant un seul script.

En atteignant tous les objectifs énumérés ci-dessus, vous gagnez de nombreux avantages qui rendent le processus de développement logiciel plus ordonné.

1. Vous pouvez rapidement reconstruire les environnements de développement. Un des plus gros problèmes avec les projets ayant une mauvaise automatisation est les constantes différences entre le fonctionnement et l'exécution du logiciel en production par rapport aux environnements de développement et de test. En raison du fait que les changements entre environnements doivent être répliqués à la main, cela est soit fait rarement, soit pas du tout. Chaque environnement a quelques particularités spécifiques, et s'il y en a beaucoup, ce problème s'aggrave encore davantage. Ainsi, le risque que le code ou une configuration créée dans un environnement fonctionne différemment dans un autre devient élevé. Les reconstructions rapides d'environnement automatisées éliminent ce problème dans son ensemble.
2. Il n'y a qu'une seule source de vérité sur l'état actuel du projet : Le Build. La construction du logiciel vous donne une image fidèle de ce à quoi ressemble le code et comment il fonctionne. L'évaluation des résultats est claire, et il n'y a pas de problèmes comme “Ça marchait sur mon ordinateur” ou “Ça marche en dev mais pas dans le test.” Une construction fraîche et automatisée d'un projet est la seule chose qui subit une évaluation.
3. Vous pouvez “construire” le logiciel et tester son déploiement dans l'environnement de test jusqu'à obtenir l'effet désiré et une garantie que le déploiement se déroulera exactement comme prévu et que les résultats seront prévisibles.

En d'autres mots, les avantages de l'automatisation de build peuvent être résumés comme suit :

1. “Vous savez où vous en êtes” – vous pouvez avoir un certain degré de certitude quant à l'état actuel de votre logiciel.
2. Tout le monde travaille sur la même version.
3. Il y a une méthode unique et objective pour vérifier si quelque chose fonctionne ou non.

Cela seul peut vous éviter le sort de nombreuses équipes qui perdent beaucoup de temps à

1. vérifier pourquoi quelque chose fonctionnait dans un environnement, seulement pour échouer lorsqu'il est déployé dans un autre,
2. ou essayer de reproduire des erreurs de l'environnement de test dans un environnement de développement ou local.

Construire de manière automatisée n'est cependant que la moitié du succès. Les tests en sont l'autre moitié.

Tests automatisés

Le logiciel actuel est très complexe, comprenant souvent des centaines de milliers de lignes de code réparties sur de nombreux fichiers. De tels projets complexes utilisent de nombreuses bibliothèques et autres dépendances. Les changements dans le code et les bibliothèques ont tendance à affecter plusieurs fonctionnalités du système.

Lors de la mise en œuvre de changements, les développeurs de logiciels vérifient généralement si le code fonctionne comme prévu. Cependant, plus souvent qu'autrement, ils n'ont pas la connaissance du système ou la capacité ni le temps de vérifier si leurs changements affectent d'autres fonctionnalités du système sur lequel ils travaillent.

Il en va de même pour les testeurs - ils sont simplement incapables de vérifier l'intégralité du système pour y détecter des erreurs qui auraient pu s'y glisser lors du test de nouvelles fonctionnalités. Si sur un projet, ils effectuent effectivement tous les scénarios de test manuellement à chaque déploiement, les déploiements commencent à être fastidieux et coûteux. Chaque erreur qui est découverte et ensuite corrigée nécessite des changements dans la base de code, ce qui signifie tester l'ensemble du système à partir de zéro ou risquer des erreurs. Souvent, en utilisant de telles pratiques, cela provoque une longue spirale de tests, d'erreurs, plus de tests, plus de nouvelles erreurs... Ou, pour aggraver les choses, des tests bâclés entraînant des erreurs poussées en production.

Ce problème peut être résolu en mettant en œuvre des tests automatisés. Il existe de nombreuses méthodes de création de tests et de tests de logiciels, c'est pourquoi je ne vais pas les énumérer ici, mais juste décrire les caractéristiques requises :

1. Les tests doivent être automatisés, et ils doivent être faciles à exécuter. Chaque développeur devrait pouvoir exécuter tous les tests dans leur environnement de développement.
2. Les tests doivent être rapides car sinon ils risquent d'être ignorés en raison de leur durée d'exécution. Les tests doivent être effectués chaque fois que le logiciel est modifié. Dans une situation idéale, chaque commit serait testé, mais vous devriez certainement tester chaque morceau de code avant de le pousser vers la branche principale.
3. Les tests doivent couvrir le plus grand périmètre possible du logiciel. Le nombre de tests et la manière dont ils sont planifiés devraient permettre de tester toutes les fonctions cruciales et significatives du logiciel, et l'équipe doit être certaine que le fait que tous les tests soient réussis signifie que le logiciel fonctionne correctement. Il existe de nombreuses techniques pour estimer la couverture des tests, qui peuvent être utilisées pour contrôler le nombre de tests.
4. Les tests doivent faire partie du build. Dans une situation idéale, chaque build devrait lancer automatiquement tous les tests et afficher leurs résultats.
5. Chaque changement doit être vérifié en testant l'ensemble du système. Encore une fois, dans une situation idéale, vous testeriez chaque commit, mais souvent il suffit de tester le code avant de le fusionner avec la branche principale. Lorsqu'un développeur met à jour la branche principale avec un code qui casse le logiciel, il entrave le travail d'autres personnes qui veulent commencer à travailler sur une nouvelle tâche en utilisant le dernier build – il ne fonctionnera tout simplement pas en raison des erreurs dans le code. Les équipes qui n'utilisent pas de tests automatisés se retrouvent souvent face à un problème où un nouveau commit brise une partie du logiciel et tout le monde qui voulait travailler dessus est bloqué jusqu'à ce que l'erreur soit corrigée. Les tests automatisés empêchent de telles situations.

Les builds et les tests automatisés sont la clé du succès

Lorsque vous automatisez le processus de build, ainsi que les tests, vous finissez avec un mécanisme dans lequel vous connaissez toujours l'état de votre logiciel. Ce qui est important, avant d'ajouter de nouveaux changements, vous pouvez vérifier si oui ou non ils introduisent de nouvelles erreurs. Grâce à cela, vous pouvez pratiquement toujours décider de déployer la version actuelle du logiciel en production. De plus, vous pouvez le faire rapidement et en toute sécurité car cela sera fait par un processus automatisé, qui a été testé au préalable dans un environnement de test, identique à celui de production.

En atteignant ce niveau d'automatisation, vous pouvez développer de nouvelles fonctionnalités en toute sécurité, sachant qu'elles fonctionnent sûrement et ne cassent rien, puis déployer votre logiciel. Fondamentalement, vous éliminez le risque de casser quelque chose, et si vous trouvez une erreur, vous pouvez la corriger rapidement.

Notre expérience

Chez Droptica, nous faisons principalement du développement Drupal et du soutien Drupal, et nous essayons d'appliquer ces méthodologies à chaque projet que nous reprenons ou commençons à partir de zéro.

Généralement, le temps et le travail investis dans la création de tests s'amortissent très rapidement. Le nombre de tests manuels requis avant déploiement diminue considérablement, compensant ainsi les coûts. Les tests automatisés nous permettent de détecter toutes les erreurs et les fautes bien plus rapidement. Souvent, lorsque nous commençons à créer des tests automatisés pour un projet qui ne les a jamais utilisés auparavant, nous avons tendance à trouver de nombreuses erreurs qui n'ont jamais été détectées par quiconque auparavant.

Grâce à cela, l'équipe cesse de chercher des erreurs et passe plus de temps à développer des logiciels. L'automatisation se traduit directement par une plus grande satisfaction et confiance de nos clients et des délais raccourcis, avec un avantage supplémentaire – notre équipe est plus satisfaite de son travail.

Lorsque l'automatisation est correctement mise en œuvre et que les tests sont bien conçus, nous pouvons déployer notre logiciel même plusieurs fois par jour ou selon un calendrier prédéfini – par exemple, une fois par semaine – sans courir le risque de briser notre environnement de production. Ce qui est important, c'est que le déploiement ne prendra pas trop de temps.