Cloud

Les 4 étapes pour réussir le lancement d’une initiative…

Le DevOps : un concept séduisant mais qu’en est-il dans la pratique ? Quelles sont les étapes cruciales pour réussir la mise en place d’une initiative DevOps ? Sur quels utilitaires d’Intégration Continue (CI) et les Utilitaires de Continuous Deployment (CD) s’appuyer ?

I) Les 4 étapes pour réussir le lancement d’une initiative DevOps

1) Un audit organisationnel du service informatique rigoureux

Procédons en premier lieu à un audit au sein du Système d’Information de l’Entreprise. L’objectif est d’analyser l’organisation du service informatique. Qui est hiérarchiquement responsable de l’équipe de développement (Dev) : les Métiers, la Finance ou la DSI ?

2) Un audit organisationnel approfondi des acteurs concernés dans l’Entreprise

Auditer les entités suivantes et leurs modes de fonctionnement est nécessaire :

  • Les donneurs d’ordre, soit les Métiers, pour comprendre leurs attentes, leurs modes de communication avec les autres entités, la fréquence de leurs demandes…
  • L’équipe Dév pour prendre en compte leur utilisation éventuelle d’une méthode Agile ou d’outils Continued Integration (CI) / Continuous Delivery (CD) / Continous Deployment (CD)
  • L’équipe Architecture Applicative pour savoir comment les applications sont structurées, quelles sont leurs dépendances, …
  • L’équipe Production (Prod) avec ses impacts directs sur une initiative DevOps :
    • Le niveau de programmabilité, donc d’adhérence ou non de l’Infrastructure de Production avec les outils utilisés par l’équipe Dév
    • Les bases de données
    • Les frameworks de supervision
    • L’implication de la sécurité (le RSSI est-il intégré dans cette réflexion ?)
    • Les utilitaires d’assemblage de packages applicatifs…

Les étapes d'un projet DevOps Plan, Continuous feedback, Deploy, Operate, Integration, Continuous, Build

3) La définition précise de l’équipe Projet

Seul le résultat de cet audit permettra de définir quelle équipe, Dév ou Prod, sera hiérarchiquement en charge de l’initiative DevOps. En effet, même si une initiative de ce type est nativement transverse, elle doit reporter à une seule entité d’un point de vue Administratif.

Il est bien sur fortement recommandé que le responsable de l’initiative DevOps dispose de solides notions de Dév. Les connaissances requises ne sont pas nécessairement axées sur le langage informatique mais plutôt axées sur la Méthode (un Scrum Master étant parfaitement approprié) et Prod.

Ici, les compétences concernant l’Infrastructure ne sont pas prioritairement concernées. Cependant, les contraintes de mise en Production de nouvelles applications, les retours arrière, les dépendances…sont au premier plan.

L’organisation à définir est la suivante :

  • Un référent DevOps en synergie avec les entités Prod et Dév, ayant l’écoute des Donneurs d’Ordre
  • Des référents Dév, en méthode Agile, les Scrum Masters
  • Un accès direct au DSI, soit un lien fonctionnel direct, à défaut d’être hiérarchique.

4) La définition des Processus

Une fois l’organisation en place, il convient de définir les processus. Ceux-ci seront intimement liés aux outils qui seront utilisés.

Comme évoqué, une méthode de développement en mode Agile est très fortement recommandée. Elle est un gage de réussite de l’initiative DevOps. Nous préconisons ainsi la Méthode Scrum pour son adhérence naturelle avec les utilitaires DevOps. Les processus seront à la fois liés à la méthode Agile ainsi qu’aux utilitaires DevOps qui regroupent deux grandes familles, les outils CI et les outils CD/CD.

Un projet DevOps est constitué d'étapes comme Integration, Deploy, Operate, Conintuous Feedback, Plan, Build, ContinuousL’objectif est d’arriver à ce résultat organisationnel :

Le déploiement continu allie les équipes développements et production ( ops ) .

La mise en place d’une Infrastructure programmable, qui pourra être pilotée par les demandes de l’équipe Dév, associée aux Méthodes Agiles permettra de répondre rapidement aux demandes Métiers.

II)   …en s’appuyant sur les Utilitaires d’Intégration Continue (CI) et les Utilitaires de Continuous Deployment (CD).

  1. La sélection des Utilitaires d’Intégration Continue (CI)

Les outils d’Intégration Continue optimisent l’efficacité de l’équipe Dév. Ils n’ont pas de lien à ce niveau avec la Prod. Cependant, puisqu’ils optimisent l’efficacité de l’équipe Dév, ils participent à améliorer la qualité de réponses aux demandes des Métiers !

Pour ne reprendre que les outils les plus répandus, les besoins propres à l’Intégration Continue sont les suivants :

  • Build et gestion des dépendances : Maven,
  • Repository de code source et Versionning : Git
  • Intégration continue proprement dite : Jenkins ou Concourse
  • Repository de binaires et d’Artifacts : Nexus Repository Manager ou JFrog Artifactory
  • Analyse de la qualité du code : SonarQube
  • Analyse des risques de faiblesse du code contre les attaques, de backdoors… : la suite Nexus FW

Scasicomp s'appuie sur un écosystème de solutions pour permettre la mise en place de projets DevOps.

      2 Le déploiement des outils au sein de l’Infrastructure

L’étape suivante est de définir comment ces outils vont être déployés : on-premise, Cloud Privé ou Public ?

Ces outils sont des utilitaires logiciels. La Production se doit de les prendre en compte au même titre que tout autre logiciel installé sur le SI de l’Entreprise. Tout dépend du SLA négocié avec l’équipe Dév, et donc avec les Métiers.

Tous ces outils disposent à minima d’une version Open Source ? Cependant, elle n’apporte pas de support, pas de haute disponibilité, pas de garantie de service….

Par ailleurs, ces outils disposent d’une version Enterprise supportée par un éditeur, avec différents niveaux de richesse fonctionnelle, et donc de licences payantes.

La haute disponibilité, en fonction de la criticité des développements applicatifs, peut ainsi être assurée mais uniquement sur licence payante.

La possibilité de mutualiser la base de données d’un Git avec un Nexus Repository Manger peut être également assurée. Cependant, des contraintes spécifiques, notamment au niveau de la sauvegarde de ces bases de données, sont à prendre en compte.

Un Maven dispose d’un repository local sur la station du développeur, d’un repository central, Maven Central, et d’un repository d’Entreprise. Scasicomp sait comment gérer cette configuration et expliquer comment positionner les bases de données.

   3  Les Utilitaires de Continuous Deployment (CD)

La Livraison Continue (Continuous Delivery) ou Continuous Deployment (Déploiement Continu) utilisent les mêmes outils. Seule la façon de mise en Production diffère.

Concernant la Livraison Continue de packages applicatifs, l’application est prête à l’usage. Il suffit d’« appuyer sur le bouton » pour la basculer en Production.

Dans le Déploiement Continu, l’application est automatiquement basculée en Production dès sa mise à disposition.

Tout comme dans l’Intégration Continue, le Déploiement Continu fait partie du royaume de l’Open Source.

Les outils d’assemblage des packages applicatifs sont disponibles sur le marché depuis de nombreuses années (Chef, Puppet, SaltStack). Un outil semble s’imposer sur le marché à ce jour : il s’agit d’Ansible, principalement du fait qu’il soit agent-less.

En parallèle des outils d’assemblage des packages applicatifs, émergent les outils de gestion d’Infrastructure de type Infra-as-Code, le plus répandu étant Terraform.

L’objectif des équipes de Production sera donc de s’assurer que les composants d’Infrastructure puissent être pilotés aussi bien par Ansible que Terraform afin de provisionner instantanément les ressources d’Infrastructure pour répondre aux besoins de déploiement applicatif.




Une question ? Un projet ?
Hervé CASTAN
Hervé CASTAN
Business Development Manager Grand Sud chez SCASICOMP
hcastan@scasicomp.com