Comme probablement d'autre personnes j'ai eu un peu de mal a avoir une définition claire de ce que peut représenter le terme DevOps ; plusieurs personnes ou organisations y vont de leur point de vue.
Oui, c'est un roman, pas un guide technique, le protagoniste principal se retrouve propulsé responsable informatique et doit gérer une situation de crise sans trop savoir comment s'y prendre et c'est dans ce contexte qu'il découvre et décide de changer les méthodes et les outils utilisés. Le côté "fiction 1" rend les choses faciles à lire (pour qui lit l'anglais) et l'histoire est assez prenante. L'inconvénient est que l'on se retrouve sans "fiche pratique" et qu'il est plus difficile d'utiliser le livre comme référence par la suite.
Et on voit bien que la méthode DevOps ne concerne pas seulement les outils techniques (virtualisation/containers, tests, gestion de configuration, ...) mais aussi la communication entre les membres d'un même équipe et avec le reste de l'organisation.
Je n'ai pas appliqué de méthode DevOps à proprement parler là où je travaille (la structure n'est pas suffisamment importante) mais il y a un certain nombre d'idées que j'ai essayé de mettre en place et certaines ont vraiment apporté des améliorations.
1) si vous avez un peu d'expérience dans le domaine, vous reconnaîtrez certaines situations comme très réalistes
[^] # Re: Ma compréhension
Posté par Ellendhel (site web personnel) . En réponse au journal DevOps. Évalué à 3.
Comme probablement d'autre personnes j'ai eu un peu de mal a avoir une définition claire de ce que peut représenter le terme DevOps ; plusieurs personnes ou organisations y vont de leur point de vue.
Suite à une recommandation de Tom Limoncelli (auteur, entre autre, de Admin'sys - Gérer son temps...) j'ai lu le roman "The Phoenix Project" à ce sujet.
Oui, c'est un roman, pas un guide technique, le protagoniste principal se retrouve propulsé responsable informatique et doit gérer une situation de crise sans trop savoir comment s'y prendre et c'est dans ce contexte qu'il découvre et décide de changer les méthodes et les outils utilisés. Le côté "fiction 1" rend les choses faciles à lire (pour qui lit l'anglais) et l'histoire est assez prenante. L'inconvénient est que l'on se retrouve sans "fiche pratique" et qu'il est plus difficile d'utiliser le livre comme référence par la suite.
Et on voit bien que la méthode DevOps ne concerne pas seulement les outils techniques (virtualisation/containers, tests, gestion de configuration, ...) mais aussi la communication entre les membres d'un même équipe et avec le reste de l'organisation.
Je n'ai pas appliqué de méthode DevOps à proprement parler là où je travaille (la structure n'est pas suffisamment importante) mais il y a un certain nombre d'idées que j'ai essayé de mettre en place et certaines ont vraiment apporté des améliorations.
1) si vous avez un peu d'expérience dans le domaine, vous reconnaîtrez certaines situations comme très réalistes