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.

eZHumanCAPTCHACode reload
retour

Principes devops

Principes devops

Les termes Continuous Delivery (CD) et Continuous Integration (CI), respectivement en français Déploiement continu et Intégration continue sont très présents depuis quelques années. Dans la méthodologie AGILE, ces deux concepts s'intègrent de manière quasi-naturelle et bien souvent les équipes construisent leurs logiciels en suivant ces principes sans en avoir pleinement conscience.

Le but est de permettre l'évolution de projets de manière fluide entre la production de code, et le déploiement final.

La majeure partie des projets est généralement soumise à la vue de différentes équipes:

  • les développeurs, techniciens intégrateurs de solutions
  • les équipes fonctionnelles qui délivrent des spécifications d'intégration et qui, souvent, sont aussi testeurs de nouvelles fonctionnalités
  • les opérateurs, administrateurs système, qui vont mettre en production les versions finales

Ces 3 équipes sont disséminées dans l'entreprise, parfois géographiquement, et il n'est pas rare que la communication entre elles ne soit ni claire ni efficace. L'une des principales raisons de cette fracture est l'absence d'outils pour leur permettre de communiquer efficacement.

Le DevOps est un mouvement qui est de plus en plus adopté par les équipes techniques dans les entreprises éditrices de logiciels ou les intégrateurs de solutions (Web, mobile, vidéo, etc...). Ce principe propose de mettre en place une jonction entre le développeur et l'opérateur (ainsi que, si possible, les intermédiaires) pour réaliser efficacement et de manière maîtrisée le produit final.

Pour résumer, nous pouvons définir 3 groupes d'outils qui s'intègrent dans le processus de Continuous Delivery:

  • Le SCM ou "Source Control Management" pour "Gestion de contrôle de Sources" qui permet de rassembler le code source, les branches et les versions
  • la PIC pour "Plate-forme d'intégration continue" qui va interfacer le VCS et exécuter une série de tests, bloquer les fusions de branches en cas de problème (et forcer la revue de code), vérifier les conventions de code, et générer des rapports
  • La plate-forme de livraison qui peut être intégrée à la PIC, elle permet de contrôler une version à livrer et provisionner les cibles de production (déploiement dans un parc informatique, sur un serveur ou sur un cluster)

Tous ces groupes peuvent être un ensemble d'outils. Et c'est sur ce point que peut aussi régner la confusion. Bien que ces trois groupes soient clairement identifiés, les outils qui les portent sont parfois capables de gérer plusieurs couches du processus.

Prenons par exemple Jenkins qui est un formidable outil d'intégration continue, il est aussi très souvent utilisé comme outil de déploiement et peut très bien faire appel à Ansible ou Puppet pour provisionner les serveurs de production, après avoir créé l'objet de livraison. Dans ce cas, Jenkins va jouer sur plusieurs tableaux et prendre en charge plusieurs aspects du CI/CD.

C'est pour cela qu'il faut avant tout bien identifier quel outil fourni quel service, et avoir connaissance de la frontière jusqu'au concept suivant.

"La PIC va être l'élément central dans un flux de livraison continue puisqu'elle est l'élément qui va déclencher une procédure de déploiement automatisée, un refus de fusion et alerter les équipes."