Le DevOps c'est quoi ?

DevOps est LE terme à la mode en ce moment, il faut absolument faire du DevOps alors le DevOps c'est quoi ? 

Et bien c'est un terme un peu comme ITIL, un ensemble de bonnes pratiques quand on a dit ça on ne peut pas s'arrêter là. Il faut entrer dans les détails, dans tous les détails. Car le DevOps intervient à toutes les étapes du développement logiciel.

Microsoft - Parts Unlimited MRP
Microsoft - Parts Unlimited MRP

Voici le site de Microsoft qui présente chacune des étapes du développement logiciel "à la façon DevOps" dans une simulation complète d'une entreprise de développement logiciel, c'est vraiment top ! C'est vraiment une partie à étudier en profondeur, ce sont les équipes de Microsoft qui ont fait un effort particulièrement important pour nous présenter cet aspect de leur métier, de notre métier, le DevOps.

La simulation est vraiment complète avec un Github. Malheureusement des liens sont cassés ! Avec des cours sur par exemple "Infrastructure as Code" ; Il faut pouvoir coder scripter votre infrastructure pour en conserver une description complète et une trace reproductible et pouvoir la faire évoluer dans le temps plus facilement. Dans ce cas la définition de l'infrastructure devient le script qui devient donc comme une empreinte complète et fidèle de l'infrastructure nécessaire à l'exécution de votre application.

Inutile de vous dire que tout est codé dans le Cloud.

Lors d'un meetup sur le DevOps, j'ai noté également d'autres termes :

Terraform
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently.

Meteor

Prometheus
Power your metrics and alerting with a leading open-source monitoring solution.

Value Stream Mapping

Il y a une multitude d'outils à chaque étape du développement qui vous permettent d'assurer le Test & l'Automatisation de chacune de ces étapes quelque soit la chaîne de développement avec laquelle vous travaillez. Il y des passerelles.

Le terme DevOps vient de la volonté de rassembler deux types de ressources de l'entreprise. Les Développeurs et les Opérationnels car les problèmes de l'entreprise qui développe du logiciel ont été identifiés à la frontière des ceux deux services. 

Les Développeurs font des trucs que les Opérationnels ne peuvent pas se permettre devant le client et de l'autre côté des Opérationnels trouvent des astuces pour palier aux problèmes du système qu'ils ne rétrofitent pas aux développeurs.

Bien des problèmes viennent d'une mauvaise communication entre les opérationnels et les développeurs de ces deux services.

Le DevOps c'est une culture, une culture qui doit se répandre dans toute l'entreprise.

Donc si vous êtes un DevOps vous devez pouvoir tout reconstruire à partir de scripts faciles à mettre en oeuvre.

Il y a trop de trucs installé sur la machine du Développeur lors du déploiement de l'application cela va poser des problèmes aux Opérationnels dont l'installation du produit ne va pas fonctionner. Ils devront chercher ce qui manque !

Voilà le DevOps c'est tout cela. Si vous débutez retenez surtout que DevOps c'est un état d'esprit qui vous permet de vous sortir des pièges dans lesquels tombent toutes les équipes de développement qui ne possèdent pas cette culture cet état d'esprit.

Le Blog - Outils de Développement Logiciel
Comment devenir un ingénieur DevOps

Approche Agile plutôt que méthode Agile

Malgré l'utilisation et l'application stricte de méthodes traditionnelles, on découvre que bien des projets informatiques sont des échecs voir de véritables fiascos. L'apport de l'approche Agile est considérable dans la réussite d'un projet et elle garantie la satisfaction du client.


Méthode Agile
Les causes de l'échec des projets informatique avec l'utilisation des méthodes classiques :
  • Cahier des charges de la taille d'une encyclopédie
  • Pas de place pour l’improvisation, réfractaire au changement
  • Effet tunnel de la méthodologie du cycle en V
A la fin du projet, le client s'étonne de la non conformité aux attentes.


La méthode Agile se concentre sur la satisfaction du client et de l'utilisateur final. Elle favorise le travail collaboratif de l'ensemble de l'équipe de développement.

Cadre méthodologique Scrum

Scrum c'est un package avec le product owner et le scrum master.

Product Backlog : liste des fonctionnalités du produit triées par importance de Valeur Ajoutée ROI

Planning Poker : estimation collaborative des sprints et de leurs difficultés

Sprint Backlog : le comment ?

Stand-up meeting : réunion journalière de 15 minutes, debout pour éviter de s'éterniser

Burndown Chart : courbe d'avancement

Revue de sprint : à la fin de chaque sprint
Rétrospective de Sprint

Assistance à la Maîtrise d'Ouvrage (AMOA)

C'est quoi l'Assistance à la Maîtrise d'Ouvrage ou AMOA ? Pour y répondre, je me promène sur le site d'une SSII et je trouve les définitions suivantes :

Description de l'AMOA - Assistance à la Maîtrise d'Ouvrage 

Cette description de l'AMOA est un peu en forme de cycle en V. Avec une descente jusqu'à la phase 3, spécifications, conception, développement et une remonté jusqu'à la phase 6 : Validation puis Support technique et fonctionnel ...

Bref, bien peu d'agilité. Alors peut-on allier cycle en V et agilité ? C'est bien la question.

Littérature sur l'AMOA

La MOA, c'est le client la Maîtrise d'Ouvrage, celui qui va utiliser le résultat du projet, l'AMOA c'est son assistance l'AMOA est donc là pour assister le client pour l'aider à définir ses besoins, pour l'aider à décider des changements souhaités dans le futur système d'information.

Le métier d'AMOA est un métier de consultant, d'écoute et de formalisation pour comprendre, décrire et faire en sorte que le futur logiciel aide l’utilisateur à être plus performant dans son métier.

Une distinction est à faire entre AMOA et AMOE :

AMOA (côté client) : décide du lancement d'un projet et qui confie la réalisation à la MOE. Elle est responsable du résultat du projet, assume l'usage du produit et finance sa réalisation.

AMOE (côté réalisation) : choisie une solution technique et à fabrique/développe les logiciels correspondant au besoin des utilisateurs.

C'est quoi ITIL ?

Vous vous demandez ce que c'est ITIL par rapport à d'autres méthodologies ? Je vais essayer de trouver les éléments de réponse à cette question.

ITIL c'est un ensemble de bonnes pratiques (best practices) pour la gestion d’un système d’information, édictées par l’Office public britannique du Commerce.
On observe une augmentation continuelle de la demande de services informatiques. Fin 1980 début 1990, le gouvernement britannique (OGC) demande une étude sur les bonnes pratiques de la gestion des services.

ITIL : Informations Technologie Infrastructure Library, ensemble de livres sur les bonnes pratiques de la gestion des services informatiques.

L'activité de mise en oeuvre d'ITIL concerne principalement l'amélioration des processus existants.

Pour se faire :
  • évaluer la maturité des processus existants,
  • s'assurer de l'implication du management pour engager la démarche,
  • s'assurer que les conditions du changement culturel sont satisfaites pour modifier ou améliorer la fourniture des services.
La prise en compte des demandes clients est primordiale.
Il faut assurer la fiabilité des projets dès la conception.

Cycle de vie des projets

Principaux points visés par la méthodologie :
  • Comment organiser une production informatique ?
  • Comment améliorer l’efficacité du système d’information ?
  • Comment réduire les risques ?
  • Comment augmenter la qualité des services informatiques ?
Processus : tâche pendant laquelle des participants produisent des livrables.

ITIL V2 entre 1990 et 2004 produit deux livres :

Service Delivery :
Concerne la planification et l'amélioration à long terme de la fourniture des services liés aux technologies de l'information.

Service Support :
Se concentre sur les opérations au jour le jour et le support aux services.

Fourniture des services (Service Delivery)

Gestion des niveaux de service (SLM Service Level Management)
du financement des services
de la capacité
de la disponibilité
de la continuité
de la sécurité

Pour chacune de ces discipline on observe les points suivants :
les objectifs
le périmètre
les concepts
les bénéfices et les difficultés
la mise en place
les activité
les indicateurs
certains autres points dépendants de la discipline traitée

Service Support

Fonction Service Desk

détection des incidents 
prise des appels 
coordination des actions

Gestion des incidents 

enregistrement des incidents
processus de gestion des incidents
classification escalade et remonté

Gestion des problèmes

traitement des erreurs connues
interrelation entre les processus

Gestion de la configuration

modélisation de l'infrastructure IT
maitrise des éléments de configuration
base de données de gestion de la configuration

Gestion des changements

préparer et valider un changement
traitement des demandes de changement

Gestion de mise en production

cycle de vie et processus de distribution

Ce qui fait le succès d'ITIL

C'est non propriétaire
Non dogmatique

ITIL représente l'expérience et les pratiques cumulées des meilleurs sociétés fournisseurs de services.
Toutes les pratiques citées dans ITIL ne sont a prendre systématiquement comme étant les meilleurs pratiques.

Liens vers ITIL

https://itil.fr/
Le portail des meilleurs pratique ITIL
Il faut s'abonner : https://itil.fr/sabonner

mise à jour 2017
ITIL France

mise à jour en 2020 : www.itil.fr le nom de domaine est réservé mais pas de site correspondant on dirait bien que tout ceci ... est à l'abandon.