Devops for Growth

La Fondation Linux confirme ce mardi 12 mars la création d’une nouvelle fondation : la Continuous Delivery Foundation (CD.Foundation ou CDF). Celle-ci va chapeauter plusieurs projets open source d’intégration et de déploiement continus (continuous integration/continuous delivery ou CI/CD) d’applications et microservices.

Parmi ces projets figurent au lancement : Jenkins (serveur d’automatisation), Jenkins X (plateforme CI/CD d’applications cloud et natives Kubernetes), Tekton (composants open source pour créer des systèmes CI/CD, un projet initié par Google), Spinnaker (une plateforme de déploiement continu pour entreprises créée par Netflix).

CloudBees, Google, Netflix…

Outre Netflix et Google, CloudBees, Alibaba, Atos, Autodesk, CapitalOne, CircleCI, GitLab, Huawei, IBM, JFrog, Puppet, Red Hat et SAP figurent parmi la vingtaine de membres fondateurs de la CDF.

La Fondation du déploiement continu ainsi formée ambitionne de renforcer un écosystème centré sur l’automatisation des tests et le développement agile de logiciels.

L’approche CI/CD présente plusieurs difficultés que vous devez résoudre.

Tout le monde n’apprécie pas le changement continu. De nombreuses mises à jour opérées depuis la stack CI/CD, tels ceux concernant les bases de données back-end ou les processus métier, sont invisibles pour l’usager. D’autres ont un impact sur l’interface utilisateur, comme le renommage de fonctions, le déplacement des éléments de la barre de menu et les modifications apportées aux processus établis. Les utilisateurs ne les apprécieront pas forcément. Toute volonté de changement de l’UI doit être communiquée le plus tôt possible aux usagers. Dans la mesure du possible, elle doit s’accompagner d’une notification et d’un rapide tutoriel, à l’écran. Avec le développement en cascade, une organisation peut former le service d’assistance (ainsi que les utilisateurs) sur tous les changements à venir. Impliquez le service d’assistance dans le processus global de CI/CD et laissez le personnel voir et donner leur avis sur les évolutions avant qu’elles ne soient mises en ligne.
Les effets domino de l’approche CI/CD dans un environnement de microservices. Une petite modification peut avoir une répercussion sur plusieurs interactions distinctes. La révision d’un microservice peut se produire sans accroc, mais elle peut causer des problèmes dans d’autres chaînes de services. La gestion de la configuration permet de suivre toutes les dépendances entre les différents microservices, et l’orchestration peut alors contribuer à garantir qu’un changement n’a pas d’impact sur d’autres combinaisons d’assets et que les équipes de développement peuvent annuler les changements si nécessaire.
Qui dit changement continu dit surveillance permanente. Les changements CI/CD, de par leur nature, ont un impact sur la plateforme sur laquelle ils sont déployés. La surveillance et le reporting en temps réel sont indispensables pour comprendre et résoudre rapidement toute difficulté. Si un bout de code se comporte mal, vous devez le savoir immédiatement, avant que les erreurs ne se propagent à d’autres services et que les plaintes des usagers ne submergent le support.
La gestion des ressources doit être réactive. En l’absence de tests approfondis préalables, les développeurs et les testeurs peuvent ne pas anticiper les répercussions sur les ressources et les performances d’un changement CI/CD avant son déploiement. Pour éviter les surconsommations imprévues, il faut automatiser autant que possible la préparation et le provisionnement des workloads de manière agnostique, en utilisant des recettes et des manifestes qui définissent comment pousser les charges de travail vers les plateformes de l’organisation. Là encore, les outils d’orchestration peuvent aider à surveiller en permanence ce qui se passe sur les infrastructures IT et à prendre des mesures correctives : affecter davantage de ressources (calcul ou mémoire), limiter l’activité, réaffecter, lancer ou arrêter une instance du microservice ou de l’application, ou encore déclencher une intervention manuelle.

In my previous post, I examined the modern application and highlighted the typical approach used to build modern applications:

1. Shrink the scope.
2. Choose the right tool for the job.
3. Offload the undifferentiated pieces.
4. Connect the building blocks.
5. Automate everything.

I have talked before on the new normal for software development as part of the Visual Studio 2012 launch events and Microsoft in itself is not immune to this change.

This eMag on Data-Driven Decision Making provides an overview of how the three main activities in software delivery can be supported by data-driven decision making to increase the effectiveness, efficiency and service reliability of a software delivery organization.

Formula for highly performing teams is well known, isn't it? Maybe not so much, and John Clapham explains the challenges to reach high performance, individually and as a team.

Suivre le cycle de vie du développement logiciel
▲

Le SDLC peut intégrer tous les aspects du cycle de vie d'une applica­tion, de la planification initiale jusqu'à son retrait de la production. Dans cette section, nous examinons une partie importante du SDLC que nous appelons le pipeline de livraison, qui est généralement composé de plusieurs environnements, c'est-à-dire des cibles de déploiement pour un ensemble d'éléments, qui travaillent ensemble à la réalisation d'un objectif commun. L'enchaînement des environne­ments permet d'améliorer et de vérifier la qualité d'une application avant qu'elle ne devienne accessible par les utilisateurs. Il n'y a pas un nombre idéal d'environnements, mais nous avons identifié quatre grands types d'environnements.

Développement (DEV) : dans l'environnement de Développement, les développeurs créent et déploient du code dans un laboratoire où l'application est testée au niveau le plus élémentaire. Lorsque l'application satisfait certains critères de qualité, elle passe à l'environnement suivant.
Test d'intégration système (SIT) : dans l'environnement Test d'intégration système, l'application est testée pour garantir qu'elle fonctionne avec les applications et systèmes existants. Lorsque l'application réussit les tests d'intégration, elle est déployée dans l'environnement suivant.
Test d'acceptation des utilisateurs (UAT) : dans l'environne­ment test d'acceptation des utilisateurs, l'application est testée pour s'assurer qu'elle fournit les fonctionnalités requises pour les utilisateurs finals. Cet environnement est généralement proche de celui de la production (voir Chapitre 4). Lorsque l'application répond à ces exigences, elle est promue vers l'envi­ronnement final.
Production (PROD) : dans l'environnement Production, l'appli­cation est mise à la disposition des utilisateurs. L'analyse du comportement utilisateur de l'application (voir l'encadré) est obtenue en surveillant la disponibilité et la fonctionnalité de l'application. Tous les mises à jour ou correctifs sont intro­duits dans l'environnement DEV et suivent le même cycle.

La Figure 1-1 montre un simple diagramme de ces quatre environne­ments.
Image non disponible
Figure 1-1 : Les quatre environnements élémentaires du SLDC

Un déploiement se définit comme la promotion de composants d'une application depuis un environnement vers le suivant. Une release comprend le déploiement de toute une application ou de plusieurs applications intégrées dans un environnement de production.

La Figure 1-2 illustre la différence.
Image non disponible
Figure 1-2 : Visualisation de la différence entre une livraison et un déploiement

Exécution d'une boucle de rétroaction

Certaines pratiques de livraison de logiciels impliquent la surveillance de l'ap­plication dans tous les environnements puis le renvoi des analyses à l'équipe de développement. En fonction des nouvelles exigences, l'équipe de déve­loppement déploie l'application modifiée dans l'environnement DEV, et le cycle démarre à nouveau. Après la promotion vers chacun des environnements suc­cessifs, l'application est supervisée, et les réactions des utilisateurs sont ren­voyées à l'équipe de développement. Ce processus est connu sous le nom de boucle de rétroaction (ou feedback loop).

Monter une usine logicielle moderne c’est avant tout se poser la question du niveau d’intégration au regard de l’ambition de son entreprise et définir deux piliers essentiels : la gestion du contrôle de code source (SCM) et les pratiques combinées d’intégration et de livraison continue (CI/CD).

Keeping in touch and being cohesive as a distributed team is a challenge many face. Assigning stories from a shared backlog helped a distributed team in doing non-stop delivery, as did giving all members of the team the authority to promote to production and back-out code at need. You need to give attention to the architecture to prevent creating similar or duplicate micro-services.

Echanges avec Marie-Pia Ignace, organisatrice du Lean IT Summit qui se déroulera les 14 et 15 mars prochains à Paris.

GitOps est l'un des moyens d'implémenter les concepts CI/CD pour les applications cloud natives, en se concentrant principalement sur l'expérience de l'équipe de développement. Si votre projet souhaite une livraison plus facile, des déploiements plus fréquents et une responsabilisation de l'équipe de développement, GitOps est fait pour votre équipe. Apprenez-en un peu plus dans cet article.

Dans ce premier eMag, nous parlerons DevOps : un retour d'expérience de Déploiement Continu avec intérêts et difficultés rencontrés, ainsi qu'une perspective complémentaire autour de l'Intégration Continue, suivi d'un éclairage sur le tuning de performance et ses caractéristiques dans l'environnement actuel. Et pour finir, la gestion des logs avec une critique de LogStash Book.