Archives de catégorie : Continuous Delivery

DevOps sur PlovDev

Publié le par
1

De retour de la conférence PlovDev, j’ai eu à répondre à quelques questions pour la newsletter de mon ESN Proxiad. Si j’y suis responsable DevOps, je suis surtout un passionné et un profond convaincu de ce mouvement. Il entre dans la dynamique du surgissement d’un nouveau monde. Une ère passionnante s’ouvre à nous !

Ayant à coeur de dynamiser et partager cette nouvelle approche, je me permets de publier ici cet interview.

Welcome to the era of DevOps!

Une application est absolument tout ce qui existe et se passe entre le push et l’exploitation d’un commit. Quand on intègre cette notion, on comprend le DevOps.

Continuer la lecture →

DevOps – Présentation – 2

Publié le par
Répondre

Le rapprochement entre les équipes de développement et d’exploitation est l’élan principal du mouvement DevOps. Pour appréhender l’interactions entre ces deux équipes, il faut comprendre le cycle de vie d’une application. Si celui-ci comporte une phase initiale d’analyse des besoins et d’études de faisabilité entre autre, il passe, pour ce qui concerne notre sujet, par une chaine de montage (un workflow pour les anglophones) qui va de la conception à la mise en production. Du développement à l’exploitation.

Cette présentation est plus de la vulgarisation qu’un discours hautement académique, je prends donc le parti de la simplification et de présenter le cycle de vie comme l’adjonction de deux cycles distincts, celui du développement et celui du déploiement dans les environnements de recette et de production. On pourrait palabrer sur la pertinence de cette césure, et il est vrai que certaines méthodes voire outils ne les distinguent pas aussi franchement, mais le but avoué de cet article est de présenter les deux concepts qui ainsi s’appuient sur un cycle de vie, respectivement le Continuous Integration et Continuous Delivery (Intégration continue et Livraison continue pour les francophones).

LifeCycle-Continuous

Continuer la lecture →

Vers l’automatisation de la recette

Publié le par
Répondre

Comment ça on ne teste pas !? Bin non, ce n’est pas possible. C’est la réponse qui m’irrite le plus juste après le « on a toujours fait comme ça ». Quel est l’intérêt d’une plate-forme de tests où la moitié des jobs est en rouge ? Comment valider un tel fourbi d’erreurs ?
Dans de telles conditions il est nécessaire de connaitre par coeur les enchainements, pour opérer à des évictions, des relances, bref il est délicat et déconseillé d’automatiser ces pratiques.

Afin d’être le plus proche de la production tout en prenant en compte certaines limites des recettes, voyons donc ici un ensemble de pratiques, non pour automatiser mais pour s’y préparer. Une petite remise à plat pour éliminer tous ces incidents normaux (ça me fait mal de l’écrire). Etape nécessaire pour automatiser ses tests et tendre vers plus de Continuous Delivery.

Continuer la lecture →

De la valorisation des constantes

Publié le par
Répondre

Cas pratique ! Dans tout environnement il faut valoriser ses constantes. Que ce soit le nom de l’environnement lui-même, d’un serveur tiers, d’une arborescence… ce n’est pas ce qu’il manque. A la B. Mouret, un fichier de configuration avec toutes ces constantes est défini pour chaque environnement. Malheureusement, quand par exemple une arborescence est redéfinie, il faut, passez-moi l’expression, se pastiller l’ensemble des fichiers à réviser. Comment procéder autrement ?

Voyons donc ici un ensemble de pratiques qu’appliquera la B. Mouret pour tendre vers plus de Continuous Delivery. Au travers de ces quelques principes simples, c’est tout une uniformisation qui en découlera et en conséquence une facilité de maintenance et d’automatisation.

Continuer la lecture →

Vers le Continuous Delivery

Publié le par
Répondre

DevOps et Continuous Delivery sont les actuels mots à la mode (buzzword pour les anglophones). Après quelques lectures et présentations, certains décideurs se posent la question de l’inflexion vers de telles méthodes. Il faut bien comprendre que derrière ces mots se cache une révision complète des DSI. C’est la fin des fameux silos enfermant chacun dans une mono-tâche technicienne au profit d’un flux automatique organisé par des experts. D’aucuns disent que ce bouleversement est un tsunami, voire un big bang. Il est donc naturel que certains responsables se demandent : Comment opérer à un tel virage vers le Continuous Delivery ?

Cet article orientera vers des perspectives de réponses. Et pour cela, citons d’abord Martin Fowler, un ponte du Continuous Delivery :

You’re doing continuous delivery when:

  • Your software is deployable throughout its lifecycle

  • Your team prioritizes keeping the software deployable over working on new features

  • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

  • You can perform push-button deployments of any version of the software to any environment on demand

Continuer la lecture →

De l’intérêt du Continuous Delivery pour le business

Publié le par
Répondre

Le déploiement de tout logiciel, installation ou amélioration, est motivé par un besoin business. Et plus l’IT répond promptement à ce besoin, plus rapidement le client ou l’utilisateur interne pourra tirer rapidement profit de ce déploiement.
Cette accroche est le point de départ du concept de Continuous delivery, traduit par Livraison en continu. Cet article est une présentation conceptuelle et non technique à l’attention des décideurs et des techniciens cherchant des arguments pour inciter leurs décideurs à entrer dans le XXIème siècle.

Depuis trop longtemps, un déploiement est le bout d’une chaine bien longue d’un projet, en cascades (le fameux waterfalls). Phase après phase, un tel projet s’étale sur plus d’un trimestre. Certaines sociétés sont rythmées sur des livraisons semestrielles voire annuelles.
Aucun besoin d’études de management pour comprendre que quatre mois après le développement, il peut arriver que le codeur ne se souvienne plus de ses intentions, voire qu’il ne soit plus présent. Si un besoin de remettre l’ouvrage sur le métier se fait sentir, il est à prévoir une latence dans l’aménagement.
Nous sentons bien que nous sommes aux antipodes du concept de Continuous delivery dont le paradigme est le prompt profit.

« Until your code is in production making money or doing what it is meant to do, you have simply wasted your time. » – Chris Read

Continuer la lecture →