Intégration continue avec Python : Une
introduction
Qu'est-ce que l'intégration continue ?
L'intégration continue (CI) est la pratique qui consiste à construire et à tester
fréquemment, automatiquement et le plus tôt possible, chaque modification
apportée à votre code. Martin Fowler, auteur et développeur prolifique, définit
l'intégration continue comme suit :
"L'intégration continue est une pratique de développement logiciel dans laquelle
les membres d'une équipe intègrent leur travail fréquemment, habituellement
chaque personne intègre au moins une fois par jour - ce qui conduit à plusieurs
intégrations par jour. Chaque intégration est vérifiée par une construction
automatisée (y compris des tests) afin de détecter les erreurs d'intégration le plus
rapidement possible." (Source)
Décortiquons cela.
La programmation est itérative. Le code source se trouve dans un dépôt partagé
par tous les membres de l'équipe. Si vous voulez travailler sur ce produit, vous
devez en obtenir une copie. Vous apporterez des modifications, les testerez et les
intégrerez dans le dépôt principal. Et c'est reparti pour un tour.
Il n'y a pas si longtemps, ces intégrations étaient importantes et espacées de
plusieurs semaines (ou mois), ce qui causait des maux de tête, des pertes de
temps et d'argent. Forts de leur expérience, les développeurs ont commencé à
apporter des modifications mineures et à les intégrer plus fréquemment. Cela
réduit les risques d'introduire des conflits que vous devrez résoudre plus tard.
Après chaque intégration, vous devez construire le code source. La construction
consiste à transformer votre code de haut niveau en un format que votre
ordinateur sait exécuter. Enfin, le résultat est systématiquement testé pour
s'assurer que vos modifications n'ont pas introduit d'erreurs.
Pourquoi devrais-je m'en préoccuper ?
D'un point de vue personnel, l'intégration continue est une question de temps
pour vous et vos collègues.
En utilisant l'intégration continue, vous passerez moins de temps :
à vous inquiéter de l'introduction d'un bogue à chaque fois que vous
apportez des modifications
à réparer les erreurs commises par quelqu'un d'autre pour pouvoir intégrer
votre code
à vous assurer que le code fonctionne sur toutes les machines, tous les
systèmes d'exploitation et tous les navigateurs.
À l'inverse, vous passerez plus de temps à
à résoudre des problèmes intéressants
écrire un code génial avec votre équipe
Co-créer des produits étonnants qui apportent de la valeur aux utilisateurs.
Qu'en pensez-vous ?
Au niveau de l'équipe, il permet une meilleure culture de l'ingénierie, où l'on
fournit de la valeur rapidement et souvent. La collaboration est encouragée et les
bogues sont détectés beaucoup plus tôt. L'intégration continue
rend, vous et votre équipe, plus rapides
vous donne l'assurance que vous construisez des logiciels stables avec
moins de bogues
Garantir que votre produit fonctionne sur d'autres machines, et pas
seulement sur votre ordinateur portable
Éliminer un grand nombre de tâches fastidieuses et vous permettre de
vous concentrer sur l'essentiel.
Réduire le temps passé à résoudre les conflits (lorsque différentes
personnes modifient le même code).
Concepts de base
Il existe plusieurs idées et pratiques clés que vous devez comprendre pour
travailler efficacement avec l'intégration continue. De plus, certains mots et
expressions qui vous sont peu familiers sont souvent utilisés lorsque l'on parle
d'intégration continue. Ce chapitre vous présente ces concepts et le jargon qui
les accompagne.
Dépôt de code source unique
Si vous collaborez avec d'autres personnes sur une base de code unique, il est
courant de disposer d'un dépôt de code source partagé. Chaque développeur
travaillant sur le projet crée une copie locale et y apporte des modifications. Une
fois qu'ils sont satisfaits des modifications, ils les fusionnent avec le référentiel
central.
Il est devenu courant d'utiliser des systèmes de contrôle de version (VCS) tels
que Git pour gérer ce flux de travail. Les équipes utilisent généralement un
service externe pour héberger leur code source et gérer toutes les parties
mobiles. Les plus populaires sont GitHub, BitBucket et GitLab.
Git vous permet de créer plusieurs branches d'un dépôt. Chaque branche est une
copie indépendante du code source et peut être modifiée sans affecter les autres
branches. Il s'agit d'une fonctionnalité essentielle, et la plupart des équipes
disposent d'une branche principale (souvent appelée branche master) qui
représente l'état actuel du projet.
Si vous souhaitez ajouter ou modifier du code, vous devez créer une copie de la
branche principale et travailler dans votre nouvelle branche de développement.
Une fois que vous avez terminé, fusionnez ces modifications dans la branche
principale.
Git branch
Le contrôle de version ne se limite pas au code. La documentation et les scripts
de test sont généralement stockés avec le code source. Certains programmes
recherchent des fichiers externes utilisés pour configurer leurs paramètres et
leurs réglages initiaux. D'autres applications ont besoin d'un schéma de base de
données. Tous ces fichiers doivent être placés dans votre référentiel.
Si vous n'avez jamais utilisé Git ou si vous avez besoin d'une remise à niveau,
consultez notre Introduction à Git et GitHub pour les développeurs Python.
(Introduction to Git and GitHub for Python Developers)
Automatiser la construction
Comme indiqué précédemment, construire votre code signifie prendre le code
source brut, et tout ce qui est nécessaire à son exécution, et le traduire dans un
format que les ordinateurs peuvent exécuter directement. Python est un langage
interprété, donc sa "construction" tourne principalement autour de l'exécution
des tests plutôt que de la compilation.
Exécuter ces étapes manuellement après chaque petite modification est
fastidieux et prend du temps et de l'attention au détriment de la résolution du
problème que vous essayez de résoudre. Une grande partie de l'intégration
continue consiste à automatiser ce processus et à le faire disparaître de la vue (et
de l'esprit).
Qu'est-ce que cela signifie pour Python ? Pensez à un morceau de code plus
compliqué que vous avez écrit. Si vous avez utilisé une bibliothèque, un
paquetage ou un framework qui n'est pas fourni avec la bibliothèque standard de
Python (pensez à tout ce que vous avez dû installer avec pip ou conda), Python a
besoin de le savoir, afin que le programme sache où chercher lorsqu'il trouve des
commandes qu'il ne reconnaît pas.
Vous stockez une liste de ces paquets dans [Link] ou dans un Pipfile.
Ce sont les dépendances de votre code et elles sont nécessaires pour une
compilation réussie.
Vous entendrez souvent l'expression "casser la compilation". Cela signifie que
vous avez introduit une modification qui a rendu le produit final inutilisable. Ne
vous inquiétez pas. Cela arrive à tout le monde, même à des développeurs
seniors aguerris. Vous voulez éviter cela principalement parce que cela
empêchera tous les autres de travailler.
L'intérêt de l'IC est de permettre à chacun de travailler sur une base stable
connue. S'ils clonent un dépôt qui casse la construction, ils travailleront avec une
version cassée du code et ne pourront pas introduire ou tester leurs changements.
Lorsque vous brisez la construction, la priorité absolue est de la réparer afin que
tout le monde puisse reprendre le travail.
Introducing a breaking change to the master branch
Lorsque la construction est automatisée, vous êtes encouragé à faire des
livraisons fréquentes, généralement plusieurs fois par jour. Cela permet aux gens
de découvrir rapidement les changements et de remarquer s'il y a un conflit entre
deux développeurs. S'il y a de nombreux petits changements au lieu de quelques
mises à jour massives, il est beaucoup plus facile de localiser l'origine de
l'erreur. Cela vous encouragera également à diviser votre travail en petits
morceaux, ce qui est plus facile à suivre et à tester.
Tests automatisés
Étant donné que tout le monde apporte des modifications plusieurs fois par jour,
il est important de savoir si votre modification n'a pas cassé d'autres éléments du
code ou introduit des bogues. Dans de nombreuses entreprises, les tests font
désormais partie des responsabilités de chaque développeur. Si vous écrivez du
code, vous devez écrire des tests. Au minimum, vous devez couvrir chaque
nouvelle fonction par un test unitaire.
L'exécution automatique des tests, à chaque modification validée, est un
excellent moyen de détecter les bogues. Un test qui échoue entraîne
automatiquement l'échec de la construction. Cela attirera votre attention sur les
problèmes révélés par les tests, et l'échec de la compilation vous obligera à
corriger le bogue que vous avez introduit. Les tests ne garantissent pas que votre
code est exempt de bogues, mais ils vous protègent contre de nombreux
changements inconsidérés.
L'automatisation de l'exécution des tests vous apporte une certaine tranquillité
d'esprit car vous savez que le serveur testera votre code à chaque validation,
même si vous avez oublié de le faire localement.