- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Profitez de l'offre spéciale anniversaire de Payfit en bénéficiant des 2 premiers mois offerts : accès à l'offre
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Retrouvez dans ce guide 20 questions qui vous permettront de prendre la température auprès de vos équipes sur leur épanouissement professionnel, ainsi que nos conseils pour que le questionnaire recueille le maximum de réponses."
Obtenir le livre blanc
Dans le meilleur des cas, le développement d'un logiciel est un exercice long et complexe qui demande l'intervention de plusieurs équipes d'experts. Il est par ailleurs essentiel que ces experts soient en mesure de collaborer, ce qui n'est malheureusement pas toujours le cas. Dans ce contexte, nous vous proposons de découvrir la méthodologie Devops, qui a pour objectif d'unifier ces différents collaborateurs et de faciliter le développement d'un logiciel. Bonne lecture !
Pour un néophyte, le Devops (ou DevOps de son appellation anglophone) vient rejoindre le jargon incompréhensible du monde informatique. Il est donc important avant tout de clairement définir ce terme.
Le Devops est une contraction de deux mots - développement et opérations - et définit une méthodologie précise utilisée dans le monde de l'informatique qui a pour objectif d'unifier lesdites phases de la création d'un logiciel. Contrairement à ce que l'on pourrait croire, le Devops ne trouve pas ses origines dans la langue anglaise (ceci est suffisamment rare pour mériter une mention spéciale) ; c'est un informaticien belge du nom de Patrick Debois qui a conceptualisé le Devops en 2009. Ce même informaticien est un fervent praticien des méthodes agiles qui l'a bien évidemment inspiré dans la conceptualisation du Devops (il ne faut toutefois pas confondre le Devops et l'Agile ; ce sont deux concepts entièrement différents).
Pour comprendre pourquoi le Devops est né, il est nécessaire de faire un bond en arrière à l'époque où le développement logiciel pour les entreprises était encore une nouveauté. À cette époque, les développeurs étaient souvent des équipes restreints où il n'était pas nécessaire de cloisonner les différentes étapes de développement. Ainsi, les mêmes personnes étaient responsables à la fois de la conception et du développement du logiciel, mais également de l'administration du système et de ses évolutions.
Toutefois, avec l'avènement de systèmes plus complexes du type ERP au sein des entreprises certaines failles apparaissent dans la méthodologie employée au sein des équipes de développement. Un changement majeur dans la structure de ces équipes se fera dans les années qui suivent en adoptant des équipes plus cloisonnées. Ainsi sont nées deux équipes : l'équipe dédiée au "Build" (le développement) du logiciel, et l'équipe dédiée au "Run" (l'exploitation et l'administration) et au "Change" (les évolutions) du logiciel. Dans la théorie, cette méthodologie a pour objectif de permettre aux équipes de mieux performer dans leurs tâches, tout en travaillant main dans la main avec l'autre.
Malheureusement la réalité voit les choses différemment, et cette méthodologie montre bien vite ses propres faiblesses (des faiblesses, ironiquement, qui étaient parfois déjà présentes dans la méthodologie précédente). La faiblesse principale qui est citée par toutes les sources : le conflit d'objectifs entre les deux équipes.
Dans la gestion de projet, il existe trois contraintes notables : le coût, la qualité et le temps. Dans le développement logiciel, ces trois contraintes sont divisées parmi les deux équipes ; l'équipe du développement se concentre sur la qualité (au détriment du coût et du temps), alors que l'autre se focalise sur le coût et le temps (au détriment de la qualité). Résultat des comptes : deux équipes, deux objectifs à l'opposé l'un de l'autre. Forcément, cela crée des conflits, affectant ainsi la performance du développement logiciel.
C'est dans ce contexte que la méthodologie Devops est née, avec Patrick Debois qui cherche une solution pour (ré)unifier deux équipes polarisées et résoudre les conflits de tous par la même occasion.
Le Devops demande à ce que le développement logiciel adopte plusieurs composants importants pour son bon fonctionnement. Nous allons nous attarder sur ces composants afin que vous compreniez mieux comment une entreprise peut se mettre au Devops.
L'objectif principal : s'assurer que les deux équipes soient sur la même longueur d'onde. Comme nous l'évoquions auparavant, les deux équipes ont souvent des objectifs antagonistes ; il faut donc être en mesure de concilier cet antagonisme. Pour cela, il n'y a pas trente-six solutions : il faut convaincre les divers collaborateurs des deux équipes de l'intérêt qu'il y a d'avoir une vision globale du développement logiciel, et de laisser de côté la mentalité de "C'est pas mon problème, mais la leur". Les méthodes pour atteindre cette harmonie au niveau de l'état d'esprit sont variées (ex. les exercices de team-building), mais il est important également de retenir que changer la mentalité de vos collaborateurs ne suffira pas pour adopter définitivement le Devops. Pour ce faire il faut également...
1. Intégration continue - L'intégration de modifications au sein d'un logiciel peut être un exercice long et fastidieux ; appliquer une méthodologie d'intégration continue permet de le rendre nettement plus court. L'objectif est relativement simple : les développeurs intègrent les modifications à leur code à intervalles courts et réguliers sur une base centralisée. Cela permet ainsi de tester de manière automatisée et normalisée les nouvelles intégrations. Par conséquent, cela permet également de détecter facilement des erreurs au fur et à mesure qu'elles apparaissent, réduisant ainsi le temps nécessaire pour valider une nouvelle version d'un logiciel.
2. Livraison continue - La livraison continue s'inscrit dans la continuité logique de l'intégration continue, donnant la possibilité aux développeurs de toujours avoir une version du logiciel qui a été testé, prêt à être distribué.
3. Microservices - Un microservice est une méthode de conception logicielle. Le microservice est, vulgairement, une fonctionnalité parmi d'autres d'un logiciel, codé de manière plus ou moins indépendante avant d'être rattaché à une interface définie en amont. En bref, cette méthode de conception s'inscrit dans une logique de réduction du temps qu'il faut pour créer une nouvelle version d'un logiciel.
4. Infrastructure en tant que code - L'infrastructure en tant que code, ou Infrastructure as Code (IaC pour les adeptes), est un concept relativement complexe. Selon Wikipedia : "Souvent plébiscité dans le cadre du cloud computing, l'Infrastructure as code offre aux développeurs la possibilité d'automatiser leurs déploiements de manière à éviter les tâches manuelles ou encore de devoir écrire d'eux-mêmes les appels aux interfaces de programmation. Cette technologie constitue une réponse aux besoins des entreprises en termes de mise à l'échelle des applications axée sur l'automatisation et la simplification de l'infrastructure de projets informatiques. De manière générale, l'Infrastructure as code s'inscrit dans la mouvance plus générale du DevOps qui a pour objectif d'unifier le développement logiciel et l'administration système." Pour résumer très vulgairement ce sujet complexe, l'IaC facilite l'accès des développeurs à l'infrastructure du logiciel.
5. Surveillance et journalisation - La surveillance et la journalisation de données ne sont pas des concepts exclusifs au développement logiciel, mais il n'en reste pas moins essentiel pour ce dernier afin de voir en temps réel les problématiques relevées du côté du client ou des collaborateurs.
6. Communication et collaboration - Cela peut paraître redondant comme bonne pratique, car la communication et la collaboration se rapprochent fortement du sujet de l'état d'esprit et de la culture d'entreprise, mais il semble tout de même important de citer que ceci reste une bonne pratique essentielle dans le cadre du Devops.
Vous l'aurez compris, sans aucun doute, que le Devops n'est pas forcément facile à mettre en place ; toutefois, depuis sa conceptualisation en 2009 cette méthodologie s'est largement popularisée, et continue à devenir une des méthodes principales de développement logiciel aujourd'hui. Vous ne nous croyez pas ? Malgré le fait que le Devops est plutôt une approche ou un mouvement, sa popularité est telle que les entreprises cherchent aujourd'hui des ingénieurs "Devops" pour rejoindre leurs équipes.
Vous trouverez ci-dessous les chiffres à connaître en matière de Devops.
Aujourd'hui, 20% des projets de développement logiciel bénéficient d'une approche DevOps. D'ici 2021, ce chiffre passera à 35- 40% (source : IDC).
Selon une étude, le DevOps permet 30 fois plus de déploiements effectués pour 60 fois moins d'incidents (réduction des downtimes) et 440 fois moins de temps pour délivrer une nouvelle feature (expérience de développement plus fluide) (source : Puppet).
50% des professionnels ont déjà implémenté une stratégie DevOps et souhaitent l’étendre et 28% ont l’intention d’en mettre une en place (source : Forrester).
81% des managers pensent que le DevOps fait gagner du temps dans le processus de développement (source : Forrester).
Le code généré est de meilleure qualité dans 38% des cas (source : Puppet).
Klee Group vous explique les divers bénéfices de la méthode DevOps.
Dans ce guide, retrouvez une revue de détails des différents éléments qui composent un pipeline d'intégration et de livraison continues pour une mise en place réussie.
Comment utiliser le Cloud dans le cadre du DevOps efficacement.
Dans ce livre blanc, Xebia revient sur l'évolution du DevOps au fil des années et ses perspectives d'avenir.
Pour répondre aux exigences de rapidité du modèle DevOps en conservant une cybersécurité efficace, de nouvelles approches doivent être adoptées en matière de sécurité de l'information, comme la sécurité intégrée, l’automatisation et la prévention proactive.
Comment maximiser l'impact et le roi du DevOps ?
