Qu’est-ce que DevOps ?
Le terme ' DevOps ' est une contraction de ' développement de logiciels ' et ' Opérations informatiques .» Il s’agit d’une philosophie qui permet à de nouveaux logiciels d’être opérationnels. La fonctionnalité clé de DevOps est un pipeline cela multiplie la livraison des éléments – c’est un peu comme la planification des nomenclatures utilisée pour la production en usine. Un autre facteur notable dans la philosophie DevOps est qu'elle est très similaire au concept de développement Agile.
Le système DevOps examine le cycle de vie des logiciels du concept aux opérations et au support. Contrairement à Agile et à d'autres stratégies de développement, il existe pas de cadre défini pour DevOps. De plus, aucune obligation légale ni norme SLA n’est impliquée dans la méthodologie.
Pensée Lean
La notion de pensée maigre découle de la recherche d’une optimisation des coûts. La discipline découle des pratiques pionnières en matière de fabrication par Toyota. Le directeur essaie d'éliminer le gaspillage et s'appuie sur les conseils des employés de l'atelier plutôt que sur l'intuition de la direction.
Les méthodes de réflexion Lean entraînent l'élimination des niveaux de gestion et la fusion des équipes d'assemblage en atelier.
DevOps est la mise en œuvre informatique de la pensée Lean. Il éloigne les pratiques de gestion des services informatiques de la tendance à fonctions informatiques du secteur en responsabilités et départements distincts. Les compétences informatiques déployées dans les opérations sont tout aussi qualifiées pour réaliser le développement de logiciels et de services. Ainsi, le équipes de développement et d’exploitation peuvent être fusionnés, fournissant ainsi un pool de compétences qui pourrait être utilisé pour l’une ou l’autre exigence.
Par coïncidence, la suppression des divisions départementales supprime également le besoin de deux structures de gestion. L’expertise nécessaire au développement est renforcée par la connaissance système de l’équipe opérationnelle. La capacité du personnel du Help Desk est également utile pour recueillir les commentaires de la communauté des utilisateurs pendant la phase d'installation.
Objectifs DevOps
L’objectif principal du DevOps est de améliorer la rentabilité . Cette rentabilité vient d’une efficacité améliorée. L'unification des équipes supprime les couches de gestion et réduit les coûts de personnel. La création d'un vivier de talents pouvant être déployés dans une gamme de rôles élimine également la possibilité qu'un groupe de spécialistes soit sous-occupé tandis que d'autres techniciens ayant des compétences égales soient surchargés de travail.
Créer une utilisation plus efficace d’un personnel technique hautement rémunéré permet d’économiser de l’argent. Réduire le temps nécessaire à chaque projet réduit les coûts de personnel plus loin, produit une plus grande efficacité et améliore les profits.
Un cabinet de conseil externe devra toujours démarrer un projet en apprenant à connaître l'entreprise et ses pratiques existantes ; le personnel sur site effectuant la gestion quotidienne du système possède déjà ces connaissances. Une équipe qui travaille à la fois sur la maintenance et l’innovation est mieux à même de repérer les cause première des problèmes actuels et proposer des améliorations au système pour résoudre ces lacunes.
En supprimant les divisions entre les responsabilités informatiques, souvent appelées « silos ', DevOps supprime le besoin d'accords entre les départements. Ainsi, le temps est gagné et le temps, c'est de l'argent.
- DevOps vise à satisfaire les objectifs suivants :
- Accélérez la fréquence de déploiement
- Réduisez le temps de définition des exigences
- Accélérez les tests du système
- Réduisez les délais entre les correctifs
- Proposer des solutions composites exploitant les ressources existantes
- Réduire le temps moyen de récupération
- S'appuyer sur les relations de travail existantes
Le personnel DevOps connaît déjà la communauté des utilisateurs et les utilisateurs ont de l'expérience dans les relations avec l'équipe, réduisant ainsi l'inquiétude lors de la communication des exigences. Réduire les soupçons à l'égard de l'équipe de développement en s'appuyer sur des relations d'affaires établies réduit les délais d'investigation du projet et réduit la probabilité qu'une solution inacceptable soit proposée à plusieurs reprises jusqu'à ce que les analystes découvrent les véritables besoins des utilisateurs.
DevOps contre ITIL
DevOps est à l'opposé de ITIL . En fait, beaucoup voient le mouvement DevOps comme une réaction contre le cadre ITIL. Alors qu'ITIL segmente les fonctions informatiques en différents rôles, responsabilités et départements, DevOps fusionne les spécialisations d'équipes distinctes en un seul groupe.
Avec ITIL, les personnes qui identifient une exigence, celles qui définissent cette exigence, celles qui gèrent un projet de développement, celles qui introduisent le nouveau système et celles qui exécutent le logiciel au quotidien sont réparties en différentes équipes. DevOps considère la définition, la création, l'introduction et le fonctionnement d'un logiciel comme un continuum , comme une chaîne de production.
La stratégie DevOps soutient que les outils nécessaires à la gestion des logiciels et les connaissances nécessaires pour assister les utilisateurs du logiciel sont tous étroitement liés à la conception et à la création du package. Cet argument découle des problèmes typiques rencontrés par les entreprises qui font appel à un cabinet de conseil en développement pour créer et introduire de nouveaux systèmes pendant que le personnel interne s'occupe de la gestion des systèmes existants. Une fois que le nouveau système est prêt à être utilisé, les développeurs s'en vont, récupèrent leur paiement et ne sont plus jamais revus. Cela ne laisse aux employés du service informatique aucune idée des subtilités du nouveau logiciel.
Bien que l'on s'attende à ce que l'équipe de développement laisse derrière elle une documentation complète sur le nouveau système, celles-ci bibliothèques de documents peut souvent être trop vaste pour que quiconque puisse l’étudier de manière significative. Les techniciens d'exploitation n'ont pas le temps de lire toute la documentation avant d'être mis sur place pour répondre aux questions à ce sujet comme s'ils étaient des experts. De même, les programmes de formation dispensés lors du transfert peuvent être organisés par un cabinet de conseil en développement pour survoler les éventuels défauts du système et ne présenter qu'un nombre limité de cas d'utilisation. C'est seulement une fois le produit en fonctionnement que toutes ses capacités soient minutieusement testées et que toutes les faiblesses de sa conception soient identifiées.
Le parcours structuré d'ITIL s'appuie sur des contrats avec des limites sur Le viseur du projet. Les problèmes d’exploitation ne sont pas prévus avant que ce nouveau logiciel n’existe. Il est presque impossible de faire revenir un consultant pour résoudre les problèmes une fois qu'il a été payé pour le travail. Cela aboutit à ce que la correction de bugs soit définie comme un nouveau contrat avec des paiements supplémentaires.
Le concept DevOps nécessite une continuité entre les processus de développement et d'exploitation. L'équipe qui sera responsable du support du nouveau système doit être impliquée dans son développement afin de pouvoir comprendre parfaitement le service avec lequel ils seront censés être parfaitement familiers lors de sa mise en ligne.
Développement DevOps vs Agile
Il existe de nombreuses similitudes entre les Développement agile cadre et le concept DevOps. Tous deux estiment qu'il doit y avoir un lien fort entre le développement et les opérations et tous deux réalisent que les retours d'information sur les opérations doivent être renvoyés à l'équipe de développement. En réalité, le développement de nouveaux systèmes n’a pas de date limite – le développement se traduit par des plaintes d’utilisateurs, des exigences révisées et des corrections de bogues. L'équipe de développement doit participer dans ces révisions à long terme.
Tous les développeurs de logiciels savent que les utilisateurs finaux ne sont pas très doués pour définition des exigences . Ils ne savent pas ce qu’ils veulent jusqu’à ce qu’on leur présente quelque chose qui ne leur plaît pas. Aucune formation de la part d'un analyste de systèmes ne peut résoudre le problème des utilisateurs qui ne se présentent pas aux réunions parce qu'ils sont « trop occupés » ou qui répondent constamment au téléphone pendant les entretiens parce qu'ils sont « trop importants ».
Il existe deux manières d’aborder le problème des exigences mal définies. La première consiste à donner aux utilisateurs un délai et à leur dire qu’ils doivent payer pour tout ce qui est livré, de sorte que s’ils ne coopèrent pas, ils devront simplement accepter ce qui leur est donné. C'est l'approche de stratégies de développement structurées , comme ITIL. Les consultants en développement indépendants aiment cette méthode car elle définit clairement la portée du projet. Ils savent qu’ils pourront gagner plus d’argent une fois le projet terminé en facturant à nouveau le remplacement des parties du système livré que les utilisateurs décident de ne pas aimer.
L'autre approche pour convaincre les utilisateurs d'exprimer une exigence est de leur donner une partie du système cela ressemble à ce qu'ils ont demandé. Les utilisateurs se plaindront très rapidement d'un nouveau système, ce qui amènera l'équipe de développement à mieux comprendre ce que les utilisateurs pensaient demander. La livraison d'un système partiel évite la tragédie de s'engager dans une mauvaise voie et de ne découvrir cette erreur que lorsque le produit fini est présenté à la communauté des utilisateurs.
Développement agile utilise la pratique d'une livraison partielle pour recueillir les commentaires et compléter la définition des exigences logicielles. Cela donne au processus de développement une forme récursive . Cependant, le développement Agile a une date de fin lorsque le nouveau système sera approuvé et remis aux opérations. DevOps considère les opérations comme une continuation de l'effort de développement, il n'y a donc pas de date de fin.
Dans la stratégie DevOps, les techniciens support assurent retour dans le processus de développement ; l'équipe de développement fournit outils de surveillance et des messages de commentaires dans le logiciel pour guider le personnel d'assistance dans les opérations quotidiennes.
CI/CD
CI/CD (également connu sous le nom de CICD) est le DevOps le plus proche d'un framework. CI signifie « Intégration continue .» CD a deux significations possibles : « livraison continue ' et ' déploiement continu .» La livraison continue implique la préparation de nouvelles versions logicielles ; le déploiement continu implique des mises à jour du code source en continu vers la production. Autrement dit, chaque petite modification est mise en œuvre dans le cadre d'un déploiement continu, tandis qu'un certain nombre de modifications sont collectées pour être publiées dans le cadre d'une livraison continue.
La méthode de livraison continue est plus fréquemment rencontrée dans les logiciels développés par un producteur indépendant. Un déploiement continu est plus probable avec i développement n-maison .
L'intégration continue est une méthode de gérer des projets de développement de logiciels qui ont un certain nombre de programmeurs travaillant sur chaque module. La stratégie CI fusionne tout le code de développement à plusieurs moments de la journée. Cela ne signifie pas que les lignes de code à moitié terminées sont fusionnées dans un référentiel central. Au contraire, une étape de développement est intégrée aux résultats d’autres programmeurs.
La partie CI de CI/CD n'est pas une partie essentielle de DevOps. C’est important pour le développement Agile. Le déploiement continu est une partie importante du processus DevOps. Ceci est particulièrement important dans le modèle de développement interne qui utilise un déploiement continu. Cela tient compte de la probabilité que les opérations mettent en évidence la nécessité de petits ajustements à un logiciel apparemment considéré comme terminé.
Les techniciens d'exploitation sont experts en repérer les problèmes du système avant que les utilisateurs ne les remarquent. Ils sont également le premier point de contact pour les utilisateurs insatisfaits. Ainsi, l'équipe des opérations peut rapidement alimenter demandes d'ajustements aux nouveaux logiciels et aux corrections de bogues à l'équipe de développement et définir clairement les exigences. En tant que professionnels de l'informatique formés, le personnel opérationnel est mieux à même de définir les exigences techniques que la communauté des utilisateurs.
La stratégie de déploiement continu résout le problème problème de communication entre analystes et utilisateurs. Les développeurs fournissent ce que les utilisateurs ont demandé mais ne s’en vont pas. L'équipe des opérations est impliquée dans tests d'acceptation puis surveille les performances du code. Une fois le logiciel opérationnel, les techniciens proposent des améliorations à mettre en œuvre par les développeurs. L'équipe des opérations traduit également les plaintes des utilisateurs en spécifications techniques . Le nouveau logiciel n'est pas considéré comme terminé tant que le nouveau système n'a pas fonctionné et que le nombre d'appels d'assistance qu'il crée n'est pas réduit au minimum, ce qui signifie que le nouveau système est stable.
Un autre avantage de l'approche DevOps est que la production ou l'achat d'outils de surveillance appropriés pour gérer le nouveau système peut également être envisagé dans le cadre du processus de développement. Dans certains cas, des outils peuvent être utilisés pour suivre un projet et pour un suivi continu. Par exemple, le bibliothèque de projets seront construits pendant la phase de développement. Celui-ci peut être structuré de manière à en faire un guide et une source de référence utile pour les gestionnaires de système et le personnel d'assistance.
Adéquation DevOps
La stratégie DevOps est plus facile à mettre en œuvre là où se trouvent à la fois l'équipe de développement et l'équipe de gestion du système. géré en interne . Il n’est pas nécessaire que l’ensemble de l’équipe de développement soit composée d’employés : il est courant de compléter l'équipe de développement avec des spécialistes sur des contrats à court terme.
DevOps peut également être appliqué par les producteurs de logiciels qui intègrent leur personnel de support produit dans le processus de développement. Cela permet au Techniciens du service d'assistance pour avoir une meilleure chance de comprendre les logiciels sur lesquels ils doivent conseiller les clients. L'utilisation de DevOps dans une maison de logiciels est également utile pour identifier les failles de sécurité qui surviennent une fois le produit utilisé dans le monde réel. L'équipe de développement peut rapidement créer des correctifs et des mises à jour aux problèmes identifiés par le personnel de soutien de la réception.
Les entreprises qui externalisent leurs opérations et fonctions de support à MSP auront du mal à mettre en œuvre une approche DevOps. L'externalisation est plus adaptée à la formule ITIL de séparation des fonctions informatiques.
Le modèle de développement Agile est plus fréquemment appliqué lorsque les développeurs sont fournis et gérés par un cabinet de conseil ou un éditeur de logiciels, mais que le projet est adapté à un seul client. Développement sur mesure est de plus en plus rare dans les environnements professionnels, grâce au développement de solutions prêtes à l'emploi, telles que les systèmes ERP.
Le domaine du développement Web est une source de travail plus probable pour les équipes de développement Agile. La structure d'un site internet permet au cabinet de mettre en place très rapidement une page d'accueil puis d'ajouter des pages au fur et à mesure de leur développement. Dans le modèle DevOps, une nouvelle page sur un site doit être gérée par la propre équipe opérationnelle du client. Ce scénario place les techniciens internes dans le rôle de fournir des commentaires pour le perfectionnement du logiciel.
ArchOps
Le pensée maigre Les motivations derrière DevOps peuvent être appliquées à d’autres aspects des services informatiques. Infrastructure doit également être défini, mis en place puis géré. Ainsi, la conception initiale d'un système de bureau ou l'extension d'un système existant doit être définie, provisionnée et installée. L'équipe des opérations peut gérer et doter ce processus ainsi que des consultants supplémentaires facultatifs ajoutés à l'équipe mais sous la direction du département.
Comme pour DevOps, il n’existe pas de normes spécifiques ni de plateformes en boucle fermée pour ArchOps . Cependant, la même direction et les mêmes techniciens peuvent être utilisés pour le développement de logiciels, la configuration matérielle et l'installation du système, qui effectuent également une surveillance et une gestion continues du système mis en œuvre.
La fusion de expertise matérielle et logicielle présente des avantages évidents. La conception globale de l’infrastructure nécessite les deux éléments. La connaissance des solutions logicielles peut réduire le coût du matériel et vice versa. Comme pour le développement Agile, lorsque le système est enfin entièrement en place, une surveillance continue et les commentaires des utilisateurs peuvent être utilisés pour identifier les ajustements nécessaires qui permettront d'aligner le nouveau système sur les attentes des utilisateurs.
Opérations de données
Le domaine de gestion de données constitue une source de profit de pointe pour les systèmes informatiques, encore sous-exploitée. La stratégie de gestion Lean Thinking consistant à laisser les opérateurs sur le terrain suggérer des améliorations peut également être appliquée à l'utilisation des données que l'entreprise gère quotidiennement et ignore souvent.
Un exemple de ce champ est l'utilisation de données de ventes pour l'analyse marketing ou l'utilisation de données de transaction pour identifier les goulots d’étranglement dans les processus de l’entreprise ou les points du parcours de l’acheteur où les clients se retirent généralement.
Les opérateurs du système informatique connaissent mieux les types de données traitées par le système et la manière dont elles sont stockées. Une fois de plus, la fusion des opérateurs avec les analystes donne à l’équipe DevOps une longueur d’avance sur tout conseil externe en développement ou en analyse de données, car le personnel interne n’a pas besoin de perdre du temps à enquêter sur les opérations de l’entreprise.
Chaînes d'outils DevOps
Comme DevOps n’a pas de cadre spécifique, il n’existe aucune plate-forme capable de répondre à l’ensemble du continuum, du développement aux opérations. Cependant, il existe des outils qui prennent en charge chaque aspect du DevOps, et les responsables de la stratégie ont tendance à rassembler un ensemble de logiciels de support pour les aider dans leurs efforts.
L'ensemble des outils utilisés dans DevOps est communément appelé « » chaîne d'outils .» Chaque département DevOps détermine quelle combinaison d'outils soutient le mieux les efforts d'efficacité dans le continuum de développement et d'exploitation. Pour plus d'informations sur les composants de la chaîne d'outils, consultez Les 8 meilleurs outils d'automatisation DevOps .
Personnel DevOps
Le concept DevOps offre de meilleures perspectives pour les professionnels de l'informatique que la stratégie segmentée d'ITIL. La séparation du développement et des opérations crée deux tribus de professionnels de l'informatique.
Dans ce scénario divisé, les spécialistes du développement sont appréciés pour leur capacité à comprendre et à gérer technologie nouvelle et innovante . Ces spécialistes ont tendance à travailler pour des cabinets de conseil ou des éditeurs de logiciels, passant de client en client, introduisant des changements à chaque commande. Ainsi, les consultants en développement sont toujours à la minute près avec la technologie, mais ils ne parviennent jamais à comprendre l’état d’esprit du personnel d’une entreprise.
La nature transitoire du travail de conseil en développement signifie que les consultants sont considérés comme étrangers par les personnels des entreprises qu'ils sont amenés à améliorer. Cette image engendre le ressentiment du personnel opérationnel de l'entreprise cliente et la méfiance des utilisateurs que les consultants doivent interroger. Ces attitudes soulèvent obstacles à la coopération et augmenter le temps nécessaire à la mise en œuvre du changement.
Le personnel des opérations acquiert sa valeur grâce à son expérience avec le système d’une entreprise. Ainsi, ces professionnels de l'informatique sont plus ancré mais ils ne travaillent pas avec les nouvelles technologies. Ils s'engagent à travailler avec un système à mesure qu'il vieillit et ils apprécient réellement leur capacité à travailler avec des systèmes obsolètes, en trouvant solutions de contournement pour combler les lacunes de l’ancien système.
Le manque d’expérience avec les technologies de pointe rend les compétences du personnel opérationnel moins valorisées sur le marché du travail. Ainsi, un professionnel de l'informatique travaillant dans des cabinets de conseil en développement et en gestion peut exiger des salaires plus élevés que le personnel opérationnel.
L'utilisation du modèle DevOps permet au personnel opérationnel interne d'être plus en contact avec les nouvelles technologies. Un technicien DevOps va en obtenir plus variété de tâches , être capable de participer à des projets à grande valeur ajoutée, tels que l'analyse des besoins et les évaluations de logiciels. La stratégie DevOps offre de meilleures opportunités aux opérateurs et plus de stabilité aux développeurs. Un technicien DevOps acquiert de l'expérience et des contacts au sein de l'entreprise tout en se tenant au courant des nouvelles innovations du secteur.
Choisir une stratégie de gestion
De nombreux responsables informatiques n’ont pas le choix entre opter pour la stratégie segmentée d’ITIL ou pour l’approche unifiée de DevOps. Les exigences relatives à l'utilisation d'ITIL ont peut-être déjà été définies par les dirigeants de l'entreprise. Cependant, il existe de nombreux départements DevOps. Ainsi, si vous souhaitez passer du modèle ITIL à un environnement DevOps, vous devriez trouver de nombreuses opportunités sur le marché du travail.
