Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Continuous Delivery

Continuous Delivery

La démarche DevOps se base sur le fait que le développement logiciel et son aspect production, opérationnel, sont fortement imbriqués, et qu'ils doivent par conséquent être gérés ensemble, et ce, dès le début d'un projet.

Issue du DevOps, le Continuous Delivery est une orientation du développement logiciel consistant à livrer régulièrement et de manière automatisée.

Cette orientation nous vient des leaders du web - Google, Amazon, ... qui ont un besoin extrêmement fort de livrer en continu des améliorations de leurs services sur internet. Bien sûr, ce n'est pas si récent que de vouloir livrer ses développements de manière itérative. Dans le cadre d'une méthodologie agile, il faut par exemple livrer de manière régulière, après chaque sprint. Mais d'une part les besoins actuels de time-to-market imposent un nouveau rythme, bien supérieur, nécessitant industrialisation et automatisation des processus. Aussi Google, Facebook, Amazon, Twitter et autres, mettent en production plusieurs fois par semaine, ou même plusieurs fois par jour !

D'autre part, par rapport à une méthodologie agile classique, il ne s'agit pas uniquement de livraisons pour test, mais bien de livraison en production, données comprises, sans impact, régression ou incident !

Dans ce contexte, on ne peut pas imaginer rester avec des mises en production traditionnelles, nécessitant une intervention manuelle et une supervision humaine dédiée pendant et après la mise en production, avec aussi la recommandation de ne pas faire de mise en production le vendredi ... Au contraire, avec les outils de Continuous Delivery, chaque livraison en production doit devenir un non-évènement, ne nécessitant pas de surveillance particulière.

Pour simplifier le concept, il suffit d'imaginer que chaque niveau opérationnel de l'application est testé de manière automatique et/ou manuelle. En règle générale, les tests automatisés (tests unitaires, tests end-to-end) sont en première ligne. Lorsque l'acceptation de tests est validé à ce niveau, l'application passe aux mains de tests utilisateurs. Quand l'utilisateur valide ces tests, une "release" est effectuée. 

Le principe reste tout de même évident: le logiciel est testé, construits et déployé de manière fluide. La crainte, tout à fait légitime, est de délivrer une version en production en ne faisant confiance qu'au processus de "Livraison en continu". Faut-il faire confiance aux tests implémentés ? est-ce que ces tests suffisent ?

Pour faire un parallèle, on peut se remémorer ce qui était en vigueur pour la validation de contenu dans les outils de gestion de contenus il y a encore quelques années. Le processus était relativement lourd et n'induisait pas de souplesse. Sans impacter l'importance des phases d'édition, de validation et de mise en ligne, la latence entre ses actions engendrait une forte réduction de la dynamique de contenu.

Aujourd'hui, la philosophie a largement évolué, notamment grâce à des outils de vérification, l'utilisation de formats d'édition légers (laissant à charge la mise en forme automatisée), les anti-spam (pour les commentaires), la classification automatique, etc. Finalement, les phases du workflow existent encore mais sont fortement assistées par les outils qui permettent de soulager ces processus.

Dans un sens, le "Continuous Delivery" s'inscrit dans cette tendance visant à automatiser les contrôles, réduire les contraintes et donc à fluidifier et maîtriser le processus d'intégration. À charge de l'ensemble de l'équipe, développeurs et agents de production, de faire en sorte, ensemble, que le processus soit viable et optimal.

La livraison continue apporte également d'autres natures de gain au processus de livraison, comme la reproductibilité des opérations de déploiement.