Nothing builds–or destroys–agility like a team's commitment to continuous integration (CI). That might sound ominous (especially if your team has yet to embrace CI), but there's good news. Regardless of the technologies a team uses, chances are there's a continuous integration and automated test framework that will work for their code base. Here's what you need to know before you dive into the detail.

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.

Automated testing, continuous delivery, and continuous deployment

It is important to distinguish continuous integration from automated testing as well as continuous delivery and continuous deployment. While those development practices relate to each other, they differ essentially by how the code gets deployed to production.

Automated testing

Automated tests are tests that can be run without the need of human intervention in a repeatable way, at any time. You typically have to write down a script to test some assertions or validate the behaviour of your application. The script is then run by a machine which provides the results as an output. Automated testing is a key part of CI, but it is not enough by itself.

Livraison continue

You practice continuous delivery when your codebase is always deployable, ready to go to production in one click. While it is recommended to deploy to production as soon as you get a green build, you may decide to slow down the releases on purpose for business reasons.

Continuous deployment

Continuous deployment happens when every change to the main branch that passes the CI tests gets pushed to production without the need for human interaction. This often results in many deployments per day which provide fast feedback to the development team.

Avantages de l'intégration continue

Investing in CI results in fast feedback on code changes. Fast as in "within minutes" fast. A team that relies primarily on manual testing may get feedback in a couple hours, but in reality, comprehensive test feedback comes a day–or several days–after the code gets changed. And by that time more changes have occurred, making bug-fixing an archeological expedition with developers digging through several layers of code to get at the root of the problem.

Ce n'est vraiment pas rapide.

Les équipes agiles livrent rapidement des logiciels de qualité, sans marches de la mort ni actes d'héroïsme. Et ceci, elles le doivent à l'intégration continue.

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 sa compilation était impossible ou qu'il contenait un bogue sérieux ? Quel contretemps pour la productivité !

Deux pratiques permettent d'éviter cette situation.

Builds continus : il s'agit de compiler le projet dès qu'une modification est apportée. Dans l'idéal, le delta entre chaque build correspond à un seul lot de modifications.

Test automation: Programatic validation of the software to ensure quality. Tests can initiate actions in the software from the UI (more on that in a moment), or from within the backend services layer.

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.

And remember: to fully realize the benefits, a team must also have the discipline to pause development and address breakages right away. The energy a team invests (and make no mistake: it's an investment) in writing tests and configuring the automation is all for naught if builds are allowed to languish in a broken state. Protecting the investment in CI and protecting the quality of the code base are one and the same thing. 

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 d'unités 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 d'unités valident uniquement les composants fondamentaux du logiciel. Ils ne reflètent pas les workflows des utilisateurs, lesquels impliquent souvent l'interaction de plusieurs composants.

Dans la mesure où les tests d'unités 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 sur les API les valident en déclenchant des appels d'un module vers un autre.

Benefits: Generally easy to write, run fast, and can easily model how applications will interact with one another.

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

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 sur ses API, l'équipe peut être beaucoup plus sûre d'elle au moment de la délivrer aux clients.

Tests fonctionnels

Les tests fonctionnels s'appliquent sur des aspects plus larges de la base de code et reproduisent les workflows des utilisateurs. 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 bogues étant donné qu'ils imitent les actions des utilisateurs et testent l'interopérabilité de plusieurs composants.

Drawbacks: Slower than unit tests, and sometimes report false negatives because of network latency or a momentary outage somewhere in the technology stack.

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 mais avec l'avantage de s'exécuter 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 à coder ! 

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 dans le 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 versions stables et de développement. Lorsque le build arrive dans une branche, l'équipe est sûre de faire le merge de ce code en amont.

With branching, continuous integration, and test automation, teams can be productive and innovative while still protecting code quality. If you're ready to take the next steps, check out our step-by-step guide to getting started with CI.

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é.

Posted by Dan Radigan

8 min read

Products discussed
Bitbucket Pipelines logo
Bitbucket Pipelines: Built-in Continuous Delivery Solution