Le dossier

• Partie 1 : Interpréteur et dépendances
• Partie 2 : Environnements et configuration
• Partie 3 : Code styling
• Partie 4 : Code linting
• Partie 5 : Tests unitaires
• Partie 6 : Fixtures et Mocks
• Partie 7 : Factories
• Partie 8 : Debugging
• Partie 9 : Versionning
• Partie 10 : Hooks de pré-commit
• Partie 11 : Intégration Continue

Rappel du contexte

Cet article fait partie d'une série d'articles visant à énumérer les différents éléments de qualité à mettre en place au démarrage d'un projet.

Introduction

L'Intégration Continue (IC ou CI en anglais) fait référence à des outils permettant d'automatiser des tâches lorsque les développeurs livrent du code. Elle permet de détecter rapidement les erreurs de code, de garantir la qualité du code et d'assurer que les modifications apportées à un projet sont cohérentes avec le reste du code.

En 2023, il est devenu très simple de mettre en place une CI pour son projet, même le plus petit. Il faut donc en profiter. Dans cet article, je vais vous expliquer pourquoi vous devriez mettre en place une CI dès le début de votre projet et vous présenter les solutions les plus faciles et rapides à mettre en place.

Pourquoi mettre en place une CI dès le début de votre projet ?

Si vous avez suivi les différents articles que j'ai postés ces derniers temps, vous avez mis en place tout un tas de règles pour votre projet : Code Styling, Linting, Tests unitaires, etc. Mais, vous n'avez pas encore l'assurance que ces règles soient respectées. La CI permet de faire ça. La CI teste chaque modification dès qu'elle est intégrée dans le code. Cela permet de détecter rapidement les erreurs, de tous types, et de les corriger avant qu'elles ne se propagent dans le reste du code.

La CI est une solution d'automatisation qui permet de lancer des commandes. En se basant sur les bons outils, elle garantit la qualité du code. En testant le code à chaque modification, la CI assure que chaque modification est cohérente avec les règles établies.

Les solutions de CI les plus faciles et rapides à mettre en place

Il existe plusieurs solutions de CI, certaines plus complexes que d'autres. Jenkins, par exemple, est une grosse machine qui peut absolument tout faire. Sa mise en place demande l'installation du logiciel sur un serveur, et beaucoup de configurations et de maintenance.

Si vous débutez dans la mise en place d'une CI, il existe des solutions qui peuvent être configurées grâce à un simple fichier présent à la racine du projet. Ces fichiers décrivent des pipelines, une suite d'étapes automatisées. Si une des étapes est en échec, alors le pipeline sera noté en échec et vous aurez une alerte.

Historiquement, ces services étaient spécialisés dans ce métier. Mais, depuis quelques années, les gros hébergeurs de dépôt Git fournissent leurs propres solutions de CI.

Voici quelques solutions simples et rapides à mettre en place :

• GitHub Actions : Une solution de CI basé sur Github.
• GitLab CI/CD : La solution de CI/CD de Gitlab
• Bitbucket Pipelines : La même chose, mais pour Bitbucket.
• Travis CI : Une solution de CI populaire, qui n'est pas basé sur un hébergeur git en particulier

Par exemple, pour Bitbuket Pipelines, il suffit d'avoir un fichier bitbucket-pipelines.yml à la racine. Voici un exemple de fichier :

image: python:3.8

pipelines:
  default:
    - parallel:
      - step:
          name: Test
          caches:
            - pip
          script:
            - pip install -r requirements/ci.txt
            - coverage run --source='tominardi' tominardi/manage.py test tominardi
            - coverage html --fail-under=90
      - step:
          name: Lint code
          script:
            - pip install -r requirements/ci.txt
            - pylint ./tominardi/**/*.py --rcfile setup.cfg

Les autres solutions sont assez similaires.

Sous le capot, ces solutions s'appuient sur Docker, pour créer des images qui vont exécuter le code.

Que mettre dans sa CI ?

Pour un petit projet qui démarre, faites simple. On peut y retrouver au moins tout ce qui est présent dans les hooks de pre-commit, à savoir :

• Le code styling
• Le linter
• Les tests unitaires

Dans un premier temps, c'est suffisant. Par la suite, vous pourrez imaginer créer des builds, déployer des instances de test, etc. Vous pourrez aussi configurer vos Pull Request pour empêcher le merge tant que la CI n'est pas au vert.

Une fois que votre CI est branchée, elle doit être maintenue. Une CI qui reste au rouge sera oubliée, non utilisée, et vous prendrez très vite de la dette technique. Un échec n'est pas quelque chose de normal, et sa résolution doit être votre priorité. La CI reste au vert.

Conclusion

C'est tout pour la CI. Il y aurait énormément à dire, mais encore une fois le dossier porte sur les points à mettre en place au démarrage d'un projet :)

Le prochain article sera le dernier. On parlera d'un truc essentiel : La documentation !