Catégories
Start-up et applications

Briser les silos dans l'intégration continue et la livraison continue

Dernières années Cycle de battage médiatique DevOps de Gartner indique que l'orchestration de la chaîne d'outils DevOps est en train de quitter le pic des attentes gonflées au creux de la désillusion. Cela signifie que le marché évolue à un rythme rapide vers productivité et évolutivité.

Nous comprenons que nous devons élaborer une stratégie complète pour aborder DevOps à grande échelle, où l'intégration continue et la livraison continue (CI / CD) sont essentielles à l'efficacité.

Dans ce modèle, chacun obtient ce qu'il veut: sécurité et contrôle pour les opérateurs, liberté et rapidité pour les développeurs. Alors que nous avançons vers la pente de l'illumination DevOps et le plateau de la productivité, nous devons choisir entre quelques approches du DevOps et prendre des décisions critiques pour garantir l'efficacité.

Vous trouverez ci-dessous quelques questions fondamentales à prendre en compte, ainsi que des recommandations basées sur nos expériences avec les clients et l'état actuel de DevOps.

Temps SD:Dois-je aborder CI et CD séparément?
Rob Zuber, directeur technique de CircleCI: Lorsqu'il s'agit de résoudre les problèmes d'IC ​​et de CD, ils sont étroitement liés et doivent être abordés ensemble. La capacité à tirer parti d'un outil qui comprend les deux est précieuse, en particulier en ce qui concerne la validation des changements. Si tout ce que vous comprenez est l’état actuel de quelque chose par rapport à la façon dont vous en êtes arrivé à cet état, il est beaucoup plus difficile d’obtenir des commentaires utiles sur le processus ou de réagir efficacement en cas de problème.

L'outillage qui nous permet de faire cela, comme CI / CD avec couverture de test complète, nous donne la confiance nécessaire pour agir rapidement car nous savons que nous ne déploierons rien dans un environnement de production tant qu’il n’aura pas été testé et validé. En testant minutieusement le code avant qu'il n'atteigne la production, nous sommes en mesure de conserver les avantages de cycles de planification plus légers, de boucles de rétroaction plus courtes avec des commentaires des utilisateurs en temps réel, le tout avec une plus grande confiance dans notre code et un risque réduit. Cela a été une bonne chose.

Maya Ber Lerner, directeur technique de Quali: Cela est également vrai du point de vue de l'automatisation. La chose la plus importante dans l'automatisation est la réutilisabilité, qui a amené l'équipe Quali à aborder CI et CD ensemble du point de vue de l'infrastructure. Lorsque vous pensez à tous les efforts consacrés à l’automatisation des processus de test ou de développement, par exemple, pourquoi ne devrions-nous pas utiliser la même automatisation pour la production?

Dois-je opter pour une solution universelle ou créer moi-même une solution en utilisant l'open source?
Ber Lerner: D'après mon expérience, vous avez toujours besoin de quelqu'un pour posséder la plate-forme globale. Il s’agit donc de trouver les outils et les composants qui vous offrent les capacités dont vous avez besoin à travers la chaîne de valeur. Il s'agit plus de trouver ces couches et de décider: comment allez-vous faire CI / CD tout au long de la chaîne de valeur? Comment allez-vous gérer les secrets tout au long de la chaîne de valeur? Comment allez-vous gérer les artefacts tout au long de la chaîne de valeur? Ensuite, il devient plus horizontal plutôt que d'enchaîner les outils.

Zuber: Il existe un équilibre intéressant entre la liberté de choix et la cohérence de la normalisation. Je suis ingénieur de formation, alors j'aime bricoler et comprendre profondément comment les choses fonctionnent. Je suis également un chef de file en ingénierie et, en fin de compte, je dois réfléchir à ce qui offre le plus de valeur à mes clients. Être capable d’utiliser un petit ensemble d’outils ou de demander à quelqu'un de gérer ces outils pour moi de manière à me permettre de faire ce qui est au cœur de mon entreprise, c’est toujours ce que je recherche.

Comment dois-je aborder le déploiement d’applications et le provisionnement d’infrastructure à travers CI / CD?
Ber Lerner: Pour de nombreuses entreprises, ce n’est plus comme avant, que vous considérez les applications comme de simples artefacts qui se déplacent en aval dans le pipeline CI / CD. Aujourd'hui, on sait généralement où ces artefacts vont être déployés, ils ont chacun leur place. C'est différent d'il y a 10 ans, où nous devions déterminer toutes les différentes permutations où nos artefacts pouvaient être installés.

Maintenant, nous savons que si cela va dans notre environnement de production, nous comprenons que l'environnement de production est notre affaire. Et l'environnement de production ne se limite pas aux artefacts. C’est aussi l’infrastructure qui doit être gérée de la même manière. Il est plus facile d'examiner ces bundles ou packages d'applications qui sont hébergés sur l'infrastructure, avec les données dont ils vont avoir besoin, et de regarder cette entité et de savoir qui en est responsable.

Nous considérons l'environnement de production dans son ensemble et nous pouvons suivre les changements dans l'environnement de production. Ce n’est pas vrai pour tout le monde, mais en général, c’est là que nous voyons cela aller avec l’infrastructure en tant que code et l’infrastructure immuable qui le rend plus faisable.

Zuber: Ce point sur l'immuabilité est important. Malgré tout le chaos autour des fournisseurs dans l'évolution de la conteneurisation, l'approche a vraiment changé la donne dans notre façon de penser les environnements d'exploitation. Maintenant, je connais exactement l’environnement dans lequel un morceau de code va fonctionner et maintenant c’est l’environnement que j’exécute en production. Avoir les mêmes bibliothèques installées aux mêmes emplacements sur les mêmes versions est un très grand changement et une énorme amélioration dans le flux de travail de livraison de logiciels.

La validation de l'image de conteneur entière pour votre application via CI, puis le déploiement de celle-ci sur une infrastructure qui a également traversé un cycle de validation similaire minimise toutes les sources de changement inattendu dans votre environnement de production.

Comment intégrer la sécurité et la qualité dans DevOps?
Ber Lerner: Du point de vue de l'automatisation, l'un des points communs entre la sécurité et les tests est leur niveau de complexité. Je pense que tout le monde regarde l'environnement de production et dit qu'ils ont besoin de l'environnement de production plus tôt. Lorsque vous essayez de briser les silos, vous essayez de présenter des équipes de sécurité et de qualité qui n'ont peut-être pas les mêmes capacités de codage que les autres dans le processus, et il est facile d'oublier leurs programmes.

Permettre à chacun d'être inclus dans le processus et d'avoir accès à certaines de ces fonctionnalités, même s'il ne s'agit pas d'infrastructure en tant que magiciens du code, ou si vous ne comprenez pas vraiment comment certaines d'entre elles fonctionnent, est essentiel pour rationaliser la sécurité et le contrôle qualité.

Zuber: Comme la plupart des autres domaines de la validation logicielle, il est très utile de déplacer les tests de sécurité plus tôt dans nos pipelines. Idéalement, nous concevons avec la sécurité à l'esprit, donc cela commence par le développeur. Ensuite, nous pouvons utiliser l'automatisation dans le pipeline de livraison, comme l'analyse des vulnérabilités, l'analyse statique, l'analyse dynamique et le fuzzing, pour détecter rapidement les problèmes. Le coût est toujours inférieur si vous pouvez identifier et résoudre ces problèmes plus tôt dans le processus.

Une facette intéressante de la sécurité, cependant, est qu'avec toutes les dépendances tierces incluses dans les déploiements de logiciels de nos jours, il est fort possible qu'une vulnérabilité soit découverte dans une bibliothèque que vous utilisez même si vous n'apportez pas de modifications à votre logiciel. Il est donc important de disposer d’un programme complet d’analyse ou de suivi pour les détecter, ainsi que de l’automatisation pour mettre à jour et redéployer rapidement avec les correctifs nécessaires.

Quels sont les bons objectifs mesurables pour ce processus?
Zuber: Pour moi, cela renvoie à la confiance. J'ai besoin d'une confiance raisonnable dans ce que j'expédie et de la confiance supplémentaire que si j'ai manqué quelque chose, je peux récupérer rapidement. C’est une grande partie de ce que nous avons accompli avec la mentalité DevOps et CI / CD en particulier.

Dernièrement, l'accent a été mis sur les mesures «Accélérer»: délai d'exécution, fréquence de déploiement, temps moyen de récupération (MTTR) et pourcentage d'échec de modification. Et ils ont beaucoup de sens. Une grande partie de ce qu'ils mesurent est autour de ce que nous voyons chaque jour dans CI / CD:

  • Délai de modification -> durée du workflow
  • Fréquence de déploiement -> à quelle fréquence vous lancez un workflow
  • MTTR -> le temps qu'il faut pour passer du rouge au vert
  • Modifier le pourcentage d'échec -> taux d'échec du workflow

L’optimisation de ces quatre indicateurs clés présente d’énormes avantages et ne manquera pas d’améliorer les performances de votre équipe.

Ber Lerner: DevOps consiste essentiellement à équilibrer la vitesse et le risque. Dans les premières années, il s'agissait de sortir rapidement. La vitesse était la première chose que vous mesuriez – par exemple la fréquence de déploiement. Mais au fur et à mesure que DevOps devient plus mature, vous devez vous assurer que vous ne créez pas de risque supplémentaire, vous commencez à vous pencher sur des mesures opérationnelles comme le temps moyen de récupération et le taux d'échec de modification.

L'un des défis que nous constatons avec de nombreuses entreprises qui traversent ce parcours est la capacité de mesurer l'efficacité de leur stratégie devops, y compris les économies de ressources, le délai moyen pour les changements et la qualité des applications. Cela implique la création d'une base de référence et le suivi des progrès après le déploiement de la plate-forme.

Ce qui est intéressant pour beaucoup de nos clients, c’est le coût de l’infrastructure tout au long de la diffusion de la chaîne de valeur et s’il est possible de l’optimiser. Il ne s’agit donc pas seulement d’être très rapide, mais aussi de faire les choses de manière très sûre et très rentable et, en fin de compte, de vous rendre plus compétitif.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *