CérénIT

Agile

• Isolation Continue : choisir librement l’ordre des mises en production : récit de la migration du modèle Gitflow vers un modèle où chaque fonctionnalité est isolée dans une branche dédiée et peut être réintégrée dans la branche de production aisément et rapidement. A contrario de Gitflow où la livraison contient un ensemble de fonctionnalités, là il est possible de moduler les fonctionnalités à déployer en fonction de son avancement et des besoins de déploiement. Cela n’empêche pas de tester ses branches et de déceler les bugs, voir même leur découverte a été accélérée.

Big Data

• Genesis of M6’s Datalake : un retour d’expérience de l’équipe de M6 depuis leur usage d’une Data Management Platform d’un éditeur vers leur propre solution Hadoop avec le choix des composants et de l’infrastructure.

Container et Orchestration

• DockerCon Europe 2017 Highlights : Docker Entreprise va bientôt supporter nativement Kubernetes (en plus de Swarm), Docker for Mac et Windows vont également inclure Kubernetes (via le projet minikube).
• Compte-rendu DockerCon EU 2017 : un compte-rendu plus détaillé de la DockerCon par les gens de WeScale.
• Traefik 1.4 — Roquefort Is Here, And It’s Huge! : Custom & Security Headers, multi-architecture (arm, etc), amélioration de l’authentification, support du proxy protocol et gestion des pages d’erreurs sont notamment au programme. Il est bon de voir ce produit s’améliorer de version en version, en attendant de voir ce que donnera Sozu.

Elasticsearch

• 5 Filebeat Pitfalls To Be Aware Of : la sensibilité de yaml, le registre, le renommage/la suppressio n de fichiers de log, le multi-pipelines et l’usage CPU dans certains cas. Au passage, des recommandations d’options sur ces différents points.
• Elastic APM enters alpha : Annoncé précédemment, Elastic commence à montrer son programme d’APM (Application Performance Management) avec une version alpha. Il ne permet de monitorer que des projets python ou node.js pour le moment. Il est fourni avec une première intégration dans Kibana. Ce produit est intégré dans la version 6.0.0 rc1

Licences & Open Source

• Facebook grants full patent rights to all GraphQL users : après le débat le mois dernier sur la/les licences de ReactJS & co, Facebook a mis la spécification de GraphQL sous une licence libre (Open Web Foundation Agreement) et les implémentations Graphql.js et Relay sous licence MIT. Cela pourrait accéler le développement de l’écosystème GraphQL maintenant que les restrictions/doutes sont levés.

Mobile

• React Native et CodePush : déployer sans compter : présentation de l’outil CodePush qui permet de mettre à jour son application mobile (basée sur React Native ou Cordova) sans repasser par les store pour un certain nombre de cas. Voir les limitations en fin d’article.

(No)SQL

• Scaling the GitLab database : retour d’expérience de l’équipe de gitlab pour faire scaler la base de données du service gitlab.com. A la fin, pgpool et le hot standby ont été écartés, tout comme le sharding au profit de pgbouncer. Comme ils s’imposent d’intégrer les solutions qu’ils utilisent dans le produit (principe du eat your own food), cette solution permet d’avoir la haute disponibilité dans Gitlab Entreprise.

J’étais à DevOps Rex hier ; elle m’avait intéressé de part son intitulé :

La conférence devops 100% retour d’expérience.

En attendant les vidéos, vous pouvez déjà retrouver les slides sur le compte slideshare devopsrex.

La conférence a plutôt bien tenu son objectif au travers de 9 talks mélangeant des réussites et des échecs mais aussi des contextes de petites et grosses entreprises.

En synthèse :

• DevOps, c’est avant tout une culture, un état d’esprit et des pratiques, bien avant d’être des outils. J’en suis convaincu, la salle le semblait aussi. C’est déjà ça d’acquis mais l’audience était biaisée.
• L’agile, c’est bien car cela rapproche Métier et Développeurs mais s’il n’y a pas du DevOps dans la foulée pour déployer au fur et à mesure la valeur apportée par les cycles itératifs, c’est idiot. La valeur n’existe que si la fonctionnalité est livrée en production. Il faut donc envisager le “Biz/Dev/Ops” comme j’en ai parlé à l’E1 Conférence lors de mon talk sur le Généraliste (transcript
• Des synergies également entre DevOps et le Lean dans tout ce qui touche à la réduction de gaspillage et à l’amélioration continue : fournir l’architecture adaptée (pas de sur-engineering), itérer, etc.
• Notion de juste investissement :
  • Tout automatiser n’a pas de sens mais plutôt que d’avoir des formules complexes pour mesurer le ROI de l’automatisation, prendre simplement une règle de douleur comprise entre 1 et 10 et automatiser tout ce qui représente une douleur supérieure à 5.
  • Le juste investissement fait aussi référence à l’équilibre entre l’agilité et la flexibilité que l’on veut avoir et l’automasation/industrialisation. Cette dernière peut parfois nuire à cette agilité/flexibilité tout comme elle peut la faciliter (en ayant automatisé un sujet, on a du temps pour autre chose)
• Au delà de la notion de culture et d’automatisation, on retrouve la notion de mesure et de partage des indicateurs (KPI). La mesure permet de factualiser/objectiver les choses et d’avoir du feedback sur nos actions. En partageant nos indicateurs et en connaissant les indicateurs des équipes avec lesquelles on travaille, cela peut être utile qu’ils y aient accès mais nous pouvons aussi les prendre en compte pour nos activités.
• Dans un contexte de grande entreprise, où la maturité devops peut varier, il est plus intéressant de partager les indicateurs que d’imposer des outils. En laissant chaque équipe adopter les outils dont elle a besoin mais en remontant des indicateurs commun, on évite que des équipes perdent du temps à réimplmenter leurs pratiques actuelles dans un autre outil sans leur apporter une réelle valeur ajoutée mais on leur demande de remonter des indicateurs communs afin de pouvoir évaluer la progression d’ensemble de l’entreprise.
• Pour mettre en place une démarche DevOps, s’il faut bien partir de la littérature existante, il convient surtout de la contextualiser à son entreprise et ensuite aux équipes voire à l’application concernée afin d’être pertinent.
• Comme tout “transformation”, il est important d’avoir un management facilitateur a minima voir sponsor. Le succès se fait tant via des initiatives bottom/up que top/down. S’il est important que les objectifs soient définis globalement et éventuellement par le management, il est tout aussi important de laisser une forte autonomie aux équipes opérationnelles pour leur permettre de trouver leur organisation afin de répondre à ses objectifs.

Pas de véritable découverte durant cette conférence pour moi. Plutôt une confirmation et une objectivation d’opinions et/ou d’intuitions que je pouvais avoir jusqu’à présent et de quoi alimenter certaines réflexions.

Une journée intéressante, même si j’aurais apprécié avoir une conférence plus orientée “DevOps depuis les tranchées” et avec un peu moins de recul/hauteur.