Intégration continue

Développez l'agilité de votre équipe grâce à un feedback accéléré. Parce que votre avancement est tributaire de la vitesse de vos tests.

Dan Radigan Dan Radigan
Parcourir les rubriques

Rien de tel que l'engagement d'une équipe envers l'intégration continue (CI) pour renforcer (ou détruire) l'agilité. L'idée peut paraître inquiétante (en particulier si votre équipe n'a pas encore adopté l'intégration continue), mais bonne nouvelle : quelles que soient les technologies utilisées par l'équipe, il existe certainement un framework avec intégration continue et tests automatisés qui sera compatible avec sa base de code.

Qu'est-ce que l'intégration continue ?

L'intégration continue consiste à intégrer systématiquement les changements de code dans la branche principale d'un dépôt et à les tester le plus rapidement et le plus souvent possible. Dans l'idéal, les développeurs intégreront leur code quotidiennement, voire plusieurs fois par jour.

Avantages de l'intégration continue

L'investissement dans l'intégration continue accélère le feedback sur les changements apportés au code. Un feedback désormais disponible en quelques minutes. Une équipe qui s'appuie essentiellement sur des tests manuels recevra peut-être un feedback quelques heures après mais, en réalité, un feedback complet sur les tests arrive plutôt un jour, voire plusieurs, après le changement de code. Et entre-temps, d'autres changements y auront été apportés. La correction des bugs devient une expédition archéologique, où les développeurs doivent creuser dans différentes couches de code pour atteindre la racine du problème.

Ce n'est vraiment pas rapide.

Préserver la qualité grâce à des builds continus et à l'automatisation des tests

Combien d'entre nous, en téléchargeant le tout dernier code source, se sont rendu compte que leur compilation était impossible ou qu'elle contenait un bug sérieux ? Rien de mieux pour anéantir la productivité !

Deux pratiques permettent d'éviter cette situation.

Builds continus : faire un build du projet dès qu'un changement est apporté. Dans l'idéal, le delta entre chaque build est un ensemble de changements unique.

Automatisation des tests : il s'agit de la validation programmatique du logiciel en vue d'en garantir la qualité. Les tests peuvent déclencher certaines actions dans le logiciel depuis l'interface utilisateur (nous y reviendrons) ou depuis la couche de services back-end.

Ces deux pratiques peuvent être comparées au beurre et à la confiture sur du pain grillé : le goût est bon séparément, mais c'est encore mieux ensemble ! L'intégration continue associe les builds continus et l'automatisation des tests pour s'assurer que chaque build évalue également la qualité de la base de code.

Et souvenez-vous : pour tirer pleinement parti de tous ces avantages, l'équipe doit également s'obliger à interrompre provisoirement le développement et à traiter les pannes immédiatement. L'énergie qu'une équipe investit (et ne vous y trompez pas, c'est bien un investissement) dans la création de tests et la configuration de leur automatisation est réduite à néant si elle laisse les builds non fonctionnels croupir. La protection de l'investissement dans l'intégration continue et la protection de la qualité de la base de code sont bel et bien la même chose.

Tests dans l'intégration continue : unité, API et tests fonctionnels

L'intégration continue comporte deux phases majeures. La première consiste à s'assurer de la compilation du code. (Ou, dans le cas de langages interprétés, le simple assemblage des différentes pièces.) La seconde phase consiste à s'assurer que le code fonctionne comme prévu. Le moyen le plus sûr d'y parvenir est d'utiliser une série de tests automatisés qui valident tous les niveaux du produit.

Tests d'unités

Les tests unitaires sont exécutés très près des composants fondamentaux du code. En termes de garantie de la qualité, ils forment la première ligne de défense.

Avantages : faciles à créer, ils s'exécutent rapidement et reproduisent strictement l'architecture de la base de code.

Inconvénients : les tests unitaires valident uniquement les composants fondamentaux du logiciel. Ils ne reflètent pas les workflows utilisateur, lesquels impliquent souvent l'interaction de plusieurs composants.

Dans la mesure où les tests unitaires expliquent comment le code doit fonctionner, les développeurs peuvent les réviser afin d'actualiser leurs connaissances sur cet aspect du code.

Tests sur les API

Un bon logiciel est un logiciel modulaire, qui permet une séparation plus claire des tâches entre plusieurs applications. Les API correspondent aux points de contact entre différents modules. Les tests d'API les valident en déclenchant des appels d'un module vers un autre.

Avantages : généralement faciles à créer, ils s'exécutent rapidement et peuvent facilement reproduire les interactions entre les applications.

Inconvénients : dans les aspects simples du code, les tests d'API peuvent imiter certains tests unitaires.

Dans la mesure où les API correspondent aux interfaces entre différentes parties de l'application, elles sont particulièrement utiles lors de la préparation d'une livraison. Lorsqu'un build candidat pour une livraison passe tous les tests d'API, l'équipe peut être beaucoup plus sûre d'elle au moment de la livrer aux clients.

Tests fonctionnels

Les tests fonctionnels s'appliquent sur des aspects plus larges de la base de code et reproduisent les workflows utilisateur. Dans les applications web, par exemple, HTTPUnit et Selenium interagissent directement avec l'interface utilisateur pour tester le produit.

Avantages : ils sont plus susceptibles de détecter les bugs, étant donné qu'ils imitent les actions des utilisateurs et testent l'interopérabilité de plusieurs composants.

Inconvénients : plus lents que les tests unitaires, ils génèrent parfois des faux négatifs en raison de la latence du réseau ou d'une panne momentanée quelque part dans la pile technologique.

Les équipes estiment souvent qu'en s'approchant du workflow réel de l'utilisateur, la vitesse des tests automatisés diminue. HTTPUnit est plus rapide, puisqu'il ne s'agit pas d'un navigateur web à part entière. Selenium fonctionne à la même vitesse que le navigateur web, à la différence près qu'il s'exécute sur plusieurs navigateurs web en parallèle. Malgré ces mises en garde, les tests fonctionnels sont extrêmement utiles et fournissent un feedback beaucoup plus rapidement que ne le feront jamais des testeurs humains.

Et à propos…

Certains testeurs considèrent les tests automatisés comme une menace existentielle. Mais cette opinion manque de vision et ne pourrait être plus éloignée de la vérité. Libérés de la corvée que représentent les tâches répétitives liées aux tests, les testeurs peuvent consacrer leur temps à l'analyse des risques, à la planification des tests et à l'acquisition de nouvelles compétences, comme apprendre à programmer !

Accélérer votre intégration continue

Chez Atlassian, nous faisons tout pour que les développeurs continuent à innover et que nos bases de code restent intègres. Nous mettons particulièrement l'accent sur le resserrement de la « boucle de feedback interne », à savoir le temps nécessaire pour mettre en œuvre des changements et obtenir les résultats des tests.

L'exécution de tests automatisés peut rapidement s'allonger et étirer la durée des builds. Une stratégie consiste à paralléliser les tests automatisés sur plusieurs serveurs (ou « agents de build »). Le serveur d'intégration continue exécute ainsi en réalité 2, 20, voire 200 tests simultanément. Grâce aux technologies cloud, le processeur peut être facilement adapté pour répondre aux besoins de votre équipe de développement au fur et à mesure de l'expansion de vos suites de tests. Toutefois, le processeur n'est pas illimité. Testez chaque aspect du code de façon complète, mais pas redondante. En effet, les tests redondants gonflent la durée du build (et gaspillent le processeur). Plus vite les ingénieurs reçoivent le feu vert, plus vite ils peuvent passer à l'élément suivant dans le backlog.

Création de branches et intégration continue : une association de rêve !

Beaucoup d'équipes évitent la création de branches en raison des problèmes rencontrés lorsqu'elles doivent faire un merge. Les nouvelles technologies en matière de contrôle de versions, telles que Git, facilitent la création de branches et le merge. Pour vous assurer que la ligne de code principale (« master » en jargon Git) reste intègre, exécutez le même niveau d'intégration continue sur l'ensemble des branches de version stables et de développement. Lorsque le build arrive dans une branche, l'équipe est sûre de merger ce code en amont.

Grâce à la création de branches, l'intégration continue et l'automatisation des tests, les équipes peuvent être productives et innovantes, tout en continuant à préserver la qualité du code. Si vous êtes prêt à passer aux étapes suivantes, consultez notre guide pas-à-pas pour vous lancer dans l'intégration continue.

Le meilleur côté du développement Agile : livrer régulièrement des logiciels performants, avec une dette technique réduite au minimum et sans compromis en termes d'ingéniosité.

suivant
Design