L’automatisation va au-delà de l’intégration continue : un avantage concurrentiel
(String: )
Comprendre les enjeux de l'automatisation fait désormais partie de votre responsabilité de dirigeant, car elle impacte directement votre croissance à court et long terme.
(String: <p> </p>
<p>Cet article sous forme de hands-on lab est fait pour que vous puissiez dérouler les expérimentations vous même. Il contient tout ce dont vous aurez besoin comme étapes, de l’installation du cluster GKE (Google Kubernetes Engine) à la création d’expérimentations en passant par le déploiement d’une application-sujet pour vos expériences. Vous pouvez lire cet article pour vous acclimater au sujet et anticiper les étapes mais nous vous recommandons de prévoir un peu de temps devant vous si vous voulez suivre le lab.</p>)
Cet article sous forme de hands-on lab est fait pour que vous puissiez dérouler les expérimentations vous même. Il contient tout ce dont vous aurez besoin comme étapes, de l’installation du cluster GKE (Google Kubernetes Engine) à la création d’expérimentations en passant par le déploiement d’une application-sujet pour vos expériences. Vous pouvez lire cet article pour vous acclimater au sujet et anticiper les étapes mais nous vous recommandons de prévoir un peu de temps devant vous si vous voulez suivre le lab.
Créer une forge logicielle GitLab / Kubernetes hébergée chez Scaleway
(String: <h2 id="-la-d-couverte-de-scaleway">À la découverte de Scaleway</h2>
<p>La souveraineté numérique est aujourd’hui un enjeu important pour un nombre grandissant d’entreprises. Au-delà de la technique, les considérations éthiques et géopolitiques poussent souvent à des choix locaux dans la mesure du possible. Or, même si nous observons de nombreux fournisseurs cloud français, la majorité se concentre sur les offres d’Infrastructure as a Service avec peu ou pas de services managés. À l’heure où le service managé devient une norme pour une grande partie des entreprises, cela représente un gros manque à leurs offres.</p>)
À la découverte de Scaleway La souveraineté numérique est aujourd’hui un enjeu important pour un nombre grandissant d’entreprises. Au-delà de la technique, les considérations éthiques et géopolitiques poussent souvent à des choix locaux dans la mesure du possible. Or, même si nous observons de nombreux fournisseurs cloud français, la majorité se concentre sur les offres d’Infrastructure as a Service avec peu ou pas de services managés. À l’heure où le service managé devient une norme pour une grande partie des entreprises, cela représente un gros manque à leurs offres.
(String: <h2 id="introduction">Introduction</h2>
<p> </p>
<p>Nous avons vu dans la première partie du guide du <a href="https://blog.wescale.fr/2019/09/26/le-guide-de-chaos-engineering-part-1/">Chaos Engineering (CE)</a> que le CE ne peut pas avoir lieu sans expérimentations.</p>)
Introduction Nous avons vu dans la première partie du guide du Chaos Engineering (CE) que le CE ne peut pas avoir lieu sans expérimentations.
Le Chaos Engineering (CE) est une discipline d’expérimentation dans les systèmes complexes et distribués, qui vise à se rassurer sur leur comportement face à des incidents et perturbations. Dans cet article je vais m’attacher à simplement apporter les bases du chaos et quelques définitions pour poser les fondations qui nous servirons dans les articles suivants. Attachez bien vos ceintures pour ce voyage, accessible à tous, dans le monde merveilleux du Chaos Engineering. 3..2..1 ! Go !!!
Observabilité, résilience et expérience au secours des systèmes chaotiques
(String: <p>Mais les nombreux passionnés que nous sommes dans les communautés QA, Dev et Ops se sont eux aussi saisis de ce sujet, pour le rendre accessible au plus grand nombre.</p>)
Nous sommes passionnés par le “Chaos Engineering” chez WeScale et c’est assez naturellement que nous tentons de le mettre en pratique et de favoriser son adoption autour de nous. Malheureusement, cette pratique est souvent méconnue ou mal considérée dans le top management. Beaucoup savent que Netflix et sa fameuse “Simian Army” sont à l'origine de cette pratique.
(String: <h2 id="artillery-io-c-est-quoi"><a href="http://Artillery.io">Artillery.io</a> c'est quoi ?</h2>
<p>Artillery est un outil permettant de réaliser des tests de montée en charge de sites web, il est open source. Le projet est disponible sur Github (<a href="https://github.com/artilleryio/artillery">https://github.com/artilleryio/artillery</a>).</p>)
Artillery.io c'est quoi ? Artillery est un outil permettant de réaliser des tests de montée en charge de sites web, il est open source. Le projet est disponible sur Github (https://github.com/artilleryio/artillery).
(String: <p>Comme tout buzzword qui se respecte, le DevOps est largement galvaudé et perd son sens original. À force de l’entendre utilisé à toutes les sauces, nous sommes proches de l’indigestion.<br>Aussi ai-je décidé de me fendre d’un article pour tenter de combattre les idées reçues. Prenons en quelques unes, pour leur tordre le cou une bonne fois pour toute.</p>)
Ces derniers temps, DevOps est le terme en vogue. Toutes les entreprises cherchent à obtenir leur badge DevOps. C’est, bien sûr, une formidable opportunité pour améliorer notre façon de réaliser les projets. Mais c’est aussi un grand risque de reproduire nos travers historiques.
(String: <p>Rapide rappel, DevOps est né il y a environ une dizaine d'années, et plus précisément en 2007, de la tête d'un certain Patrick Debois. Il dressa un constat affligeant concernant les relations entre dev et ops : il n'y en a pas et s'il y en a, elles ne sont pas bonnes.</p>
<p><br>En d'autres termes, il s'agit de deux mondes dont les préoccupations et les enjeux ne sont pas identiques. Et très égoïstement et/ou à cause d'un management ne le permettant que trop rarement, ces deux univers restent bien éloignés et c'est mieux ainsi.<br>De ce triste constat, l'idée a germé pour trouver des axes d'améliorations d'une communication qui dépasse le système de ticketing. Soyons honnête, ce magnifique outil dans lequel dev et ops communiquent des lettres d'amours passionnées n'est clairement pas une invitation à la fluidité. À l'époque, les outils étaient assez rares pour mettre en place des processus dits DevOps (déploiement continu, livraison continue, monitoring centralisé, ...). Aujourd'hui, il en existe de nombreux et surtout des plateformes massivement automatisables. Mais les outils et plateformes ne font pas tout et notre ami Patrick Debois, accompagné d'un certain nombre d’acolytes, déterminèrent que DevOps représentait aussi et surtout un enjeu pour l'état d'esprit (mindset). Vous trouverez d'ailleurs une idée de l'ambiance générale en lisant cet <a href="https://blog.wescale.fr/2016/10/06/devopswescale/">article</a>.</p>)
Rapide rappel, DevOps est né il y a environ une dizaine d'années, et plus précisément en 2007, de la tête d'un certain Patrick Debois. Il dressa un constat affligeant concernant les relations entre dev et ops : il n'y en a pas et s'il y en a, elles ne sont pas bonnes. En d'autres termes, il s'agit de deux mondes dont les préoccupations et les enjeux ne sont pas identiques. Et très égoïstement et/ou à cause d'un management ne le permettant que trop rarement, ces deux univers restent bien éloignés et c'est mieux ainsi. De ce triste constat, l'idée a germé pour trouver des axes d'améliorations d'une communication qui dépasse le système de ticketing. Soyons honnête, ce magnifique outil dans lequel dev et ops communiquent des lettres d'amours passionnées n'est clairement pas une invitation à la fluidité. À l'époque, les outils étaient assez rares pour mettre en place des processus dits DevOps (déploiement continu, livraison continue, monitoring centralisé, ...). Aujourd'hui, il en existe de nombreux et surtout des plateformes massivement automatisables. Mais les outils et plateformes ne font pas tout et notre ami Patrick Debois, accompagné d'un certain nombre d’acolytes, déterminèrent que DevOps représentait aussi et surtout un enjeu pour l'état d'esprit (mindset). Vous trouverez d'ailleurs une idée de l'ambiance générale en lisant cet article.