Sommaire

GTFS-RT : le guide des bonnes pratiques à adopter

Suivez ces quelques étapes pour améliorer la visibilité en temps réel de votre réseau de transports auprès de vos voyageurs

En savoir +

Tests automatisés et intégration continue selon la démarche Agile

publié le
April 25, 2023
Produit
Nicolas Jaulin, CEO
Nicolas Jaulin
CEO
Illustration de l'article : Tests automatisés et intégration continue selon la démarche Agile

L’intégration continue est une composante essentielle dans un environnement agile. Cet ensemble de pratiques consiste à tester de manière automatisée chaque révision de code, avant de le déployer en production. La phase de tests automatisés est complètement intégrée au flux de déploiement : lorsque le développeur code une fonctionnalité, il conçoit également les tests associés.

Tests automatisés

Une fois l’évolution implantée, le serveur d’intégration va exécuter automatiquement les tests pour vérifier qu’aucune régression n’a été introduite dans le code source. Si un problème est identifié, le déploiement n’a pas lieu et les développeurs en sont informés. Si aucune erreur n’est remontée, le serveur d’intégration peut déployer directement le code en production.

Remontée des anomalies

La remontée des erreurs se fait au quotidien : l’intégration continue permet donc aux développeurs d’avoir un retour rapide sur leur développement. Ainsi, pas besoin d’attendre plusieurs semaines pour identifier et corriger les anomalies. Résultat : moins d’anomalies sont déclarées par nos utilisateurs finaux qui sont plus satisfaits. La qualité du code est validée durant la phase de tests automatisés.

Gain de temps et diminution des anomalies

Auparavant chez Pysae, le temps de correction des erreurs, bugs et anomalies représentait jusqu’à 50 % de la charge d’occupation des développeurs. Aujourd’hui, la récurrence des tests automatisés a permis de diminuer la part des anomalies à traiter. La charge de notre équipe est équilibrée : 90 % du temps de dev est employé aux évolutions, le traitement des anomalies représentant désormais seulement 10 % de l’activité de notre équipe.

Gestion plus rapide des évolutions

La mise en place des bonnes pratiques de l’intégration continue permet aux développeurs de gérer des évolutions plus lourdes au quotidien. Le processus de déploiement continu est plus fiable. Avec l’intégration continue, les mises en production sont donc plus fréquentes. Le time-to-market est considérablement réduit. En déployant les évolutions plus rapidement, nous restons compétitifs et répondons aux attentes de nos utilisateurs.

Méthodologie de tests

Chez Pysae, nous considérons qu’il est très important de s’apercevoir le plus tôt possible des anomalies en validant tous les aspects des applications par l’intermédiaire d’un outil, GITLAB. Pour cela, nous effectuons des tests unitaires sur des fonctions de code et des tests d’intégration au quotidien.

La méthode de la pyramide de tests a été adoptée par notre équipe de Dev.

Le chantier d’évolution

Un chantier d’évolution est découpé en petits tickets autonomes et indépendants les uns des autres pour ne pas gêner leur mise en production. Un ticket représente une nouvelle fonctionnalité à coder. Chaque développeur travaille sur des tickets qui vont passer des étapes de tests avant d’être mis en production. La validation d’un ticket est soumise à des critères de qualité de la fonctionnalité concernée. Chaque ticket va passer 4 étapes de tests au total. Nous allons multiplier les tests automatiques et partiellement automatiques pour maximiser la qualité de production.

Les étapes de l'intégration continue

La procédure de mise à jour est structurée. Chaque étape doit être validée avant la mise en production de l’application. Une même application va être testée à différents niveaux du processus d'intégration continue.

Phase de déploiement

Selon la démarche agile, le travail des développeurs est rythmé par des sprints de deux semaines. A chaque fin de sprint, les différents tickets développés pendant le sprint sont mis en production. Ensuite intervient la release (version 3.3.2 de l’application Driver) qui stocke l’état du code (photographie à un instant T).

Si nous rencontrons un problème lors de la mise en production, nous effectuons un rollback. Cette action va annuler la mise en production de la nouvelle version pour revenir à la version précédente, qui fonctionne. Cette procédure peut être réalisée en quelques minutes pour garantir la qualité de l’application (retour à un état précédent maîtrisé).

Généralement, la méthodologie de tests que nous employons chez Pysae nous permet de délivrer à nos utilisateurs un produit de qualité, avec de rares retours à l’état précédent.

Une remarque, un commentaire à nous envoyer ? Nous sommes à votre écoute par email contact@pysae.com ou via le chat en ligne !

Nos derniers articles :

Retour au blog

La pénurie de conducteurs est un problème logiciel, pas seulement un problème de recrutement

Le secteur manque de conducteurs. Mais avant de recruter, avez-vous regardé combien vous en perdez faute d'outils ?

SAEIV : quel retour sur investissement pour un opérateur de transport indépendant ?

Pénalités évitées, reporting automatisé, turnover réduit : modélisation du ROI d'un SAEIV pour une flotte de 150 cars interurbains.

AVM, AVL, SAEIV : le guide terminologique pour les exploitants de transport

SAEIV, AVM, AVL... le secteur des transports publics multiplie les acronymes. Voici ce que chacun désigne.

Envie d'en voir davantage ?