Continuous ceci, continuous cela… A quoi ça rime ? Ou plutôt à quoi ça rythme ? Car l’intégration continue et le déploiement continu sont une question de rythme, oserai-je dire.

Mode ou qualité ?

Je me suis longtemps dit que tout cela ne relevait que d’une mode, comme souvent en informatique, et qu’on réinventait la roue tous les 3-4 ans, au fur et à mesure que de nouveaux ignares informaticiens arrivaient sur le marché. Car en informatique, on a tendance à refaire ce qui existe déjà (mais dont on ignore l’existence).

Or je me suis rendu compte que, sous la foultitude d’outils qui se marchent sur les pieds, il y avait au fond une amélioration possible et substantielle de la qualité du développement. A condition, comme toujours, d’employer des méthodes et des techniques à bon escient.

Définissons

As to me, l’intégration continue et le déploiement continu consiste à outiller ces phases de façon à pouvoir les reproduire rapidement et automatiquement. Ca n’est pas continu au sens premier du terme, mais plutôt rapidement et constamment.

Déployons du code de m…

On confond trop souvent (toujours ?) agilité et rapidité. Or cela n’a rien à voir. La rapidité implique d’aller vite mais sans aucun égard à la qualité de son travail. L’agilité demande d’aller vite mais surtout bien : imaginons que vous allez vite en laissant 3 anomalies majeures par cycle de développement. Au bout de 2 cycles, vous en avez 6, au bout de 3 vous en avez 9… Et vous vous retrouvez rapidement avec une application pourrie, plein de choses à corriger sans en avoir le temps ni le budget.

Donc CI/CD doit être un gage de qualité et non de rapidité. Le code que vous livrez doit faire ce qu’on lui demande, le prouver, et fournir les moyens de le prouver. Ainsi, dans les développements suivants, vous ajouterez du code et de fonctionnalités tout en vous assurant de ne rien casser de ce que vous avez fait précédemment, et c’est essentiel pour espérer aller vite.

Tant qu’à faire : le TDD

Le concept de TDD (Test Driven Development) consiste(rait) à écrire les tests avant le code : on déclare d’abord le résultat à atteindre, puis on écrit le code pour cela. C’est radical, rarement suivi à la lettre, mais ça reste intéressant dans l’idée d’un mode de développement vraiment agile.

Outillons

Je me suis longtemps perdu dans les outils nombreux et variés, et se marchant parfois sur les pieds comme je disais. Pourtant, en prenant un peu de recul, on comprend l’intérêt de tout cela et leur articulation devient plus claire.

Intégrons

Dans l’intégration, il y a plein de trucs : compilation, gestion des dépendances, tests unitaires, revue de code… Plus cette phase sera riche et productive, plus la qualité de notre développement sera élevée. Un programme qui compile, c’est bien, mais un programme qui compile, qui est bien écrit, et qui fait ce qu’on attend de lui, c’est encore mieux.

Sources

• Quand et où écrire des tests unitaires ? (test-recette.fr)
• Testing Your Code — The Hitchhiker’s Guide to Python (python-guide.org)
• Continuous Integration (CI) with GitLab
• GitLab Continuous Delivery (CD)
• Setting Gitlab CI/CD for Python application | by Lion | cubemail88 | Medium
• Step-by-Step tutorial to build a minimal CI/CD pipeline for your Python project using Travis-CI | by Youness Mansar | Oct, 2020 | Towards Data Science