Etude comparative des outils DevOps

Méthode adoptée

Afin d’assurer le bon déroulement de notre projet, nous avons opté pour la méthode agile Scrum, pour pouvoir répondre au mieux au besoin exprimé par l’entreprise en minimisant les risques de dépassement des délais dans le but d’arriver à une satisfaction partagée en préservant une bonne conduite du projet. Scrum (« la mêlée ») est une méthode agile qui s’applique à la gestion de projet. Son principe est abordé pour la première fois dans un article de Hirotaka Takeuchi et Ikujiro Nonaka intitulé « The New New Product Development Game » publié en 1986 dans la Havard Business Review. Elle a ensuite été développée dans les années 1990 et formalisée par Ken Schwaber et Jeff Sutherland en 1995 [2]. Le principe de cette méthode est de focaliser l’équipe de manière itérative sur les fonctionnalités à réaliser. Le projet est ainsi découpé en modules fonctionnels qui seront réalisés, testés et livrés par séquences itératives appelées « sprint ». Chaque sprint vise à atteindre un but à partir duquel sont choisies les fonctionnalités à implémenter dans cette phase [cf. Figure 13].

Ainsi, nous avons adapté cette méthode à notre cas, en répartissant le projet sur des sprints d’une à trois semaines. À la fin de chacune, une réunion a été tenue pour présenter les tâches réalisées durant le sprint en question tout en fixant les tâches et objectifs à atteindre durant l’itération suivante. Chaque fois qu’une différence est constatée pendant l’inspection, nous étions amenés à adapter le processus en question. Nous avons en fait, planifié des réunions hebdomadaires, en parallèle à ces Sprint-Reviews, pour présenter les actions de la période, les difficultés rencontrées ainsi que les actions de la période suivante et ses perspectives. Ceci a permis de bien fixer les objectifs à chaque incrément et de pouvoir les adapter, mais aussi, de pouvoir à tout moment compléter ou modifier la liste des fonctionnalités à réaliser pour les prochains sprints.

Planification du projet

La planification du projet est une phase inéluctable pour le management de projet. Elle permet de définir les travaux à réaliser, fixer les objectifs, coordonner les actions, maitriser les moyens, diminuer les risques, suivre les actions en cours et rendre compte de l’état d’avancement du projet. Nous avons établi en premier lieu un découpage de projet en tâches, puis un diagramme de Gantt qui permettront d’identifier les travaux à compléter en traduisant le projet en une liste de tâches à accomplir.

Outils de gestion de dépôt d’objets binaires

Un gestionnaire de dépôts d’objets binaires (binary repository manager en anglais) est un outil logiciel conçu pour optimiser le téléchargement et le stockage des objets binaires utilisés et produits dans le cadre du développement de logiciels (généralement des fichiers). Il centralise la gestion de tous les artefacts générés et utilisés par les logiciels de l’organisation (éditeur logiciel). Il permet de répondre à la problématique de complexité découlant de la diversité des types d’objets binaires, de leur position dans l’ensemble du flux de travail, ainsi que les dépendances entre eux [9]. Un dépôt d’objets binaires est un dépôt de logiciels pour les paquets, artefacts et leurs métadonnées. Il peut être utilisé pour stocker les fichiers binaires produits par l’organisation elle-même (releases et builds intermédiaires des produits) ou pour stocker les binaires tiers (dépendances) qui doivent être traités différemment pour des raisons techniques et juridiques.

Outils de gestion de configuration et automatisation Les outils de gestion de configuration sont utilisés pour contrôler les changements, les mises à jour et les modifications sur l’infrastructure d’une entreprise. Les outils gèrent l’équilibre souhaité au sein de grands environnements composés de serveurs, effectuent une supervision en continu, et assurent que l’infrastructure est configurée selon les bonnes spécifications, éliminant les risques et réduisant le temps de résolution des incidents. Ces fonctionnalités facilitent la collaboration à travers l’entreprise en éliminant les problèmes de contrôle de version et en garantissant l’uniformité des modifications. Enfin, les outils de gestion de configuration sont indispensables pour éviter les trop grandes variations entre serveurs et infrastructure, économisant de facto temps et coûts requis pour réparer les erreurs [10]. Dans la catégorie des outils de gestion de configuration trois outils sont les plus connus et utilisés par les entreprises : Ansible, Puppet et Chef. Cette étude vient pour montrer les avantages et les inconvénients de l’outil Ansible qui est proposé pour ce projet face à Puppet et Chef.

Puppet Puppet est un outil de gestion de configuration logicielle

Open Source qui assure un moyen standard de livrer et d’exploiter les logiciels, quel que soit l’endroit où ils s’exécutent. L’utilisateur doit déclarer le statut final des applications déployées et de l’infrastructure provisionnée au moyen d’un langage facile d’accès [10]. Compatible avec Unix et Windows, Puppet est livré avec son propre langage déclaratif pour décrire la configuration du système. Il existe deux éditions de l’outil : Open Source et professionnelle. Cette dernière inclut un GUI, des API et des outils en ligne de commande pour la gestion des noeuds. L’objectif de Puppet est de permettre de partager, de tester et d’appliquer des changements à travers un Datacenter, tout en garantissant visibilité et reporting pour la prise de décision et la conformité. Son véritable objectif est de mettre en oeuvre une manière élastique et standard d’automatiser le déploiement et la mise en production des applications.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Remerciements
Résumé
Abstract
Liste des tableaux
Liste des figures
Introduction générale
Chapitre 1 : Cadre générale du projet
Introduction
1.Entreprise d’accueil
1.1. Le groupe SQLI
1.2. Clients SQLI
1.3. Partenaires SQLI
1.4. Organisation SQLI Maroc
1.5. Projet AMC
2.DevOps chez SQLI
2.1. Pourquoi DevOps?
2.2. Comment démarrer une transformation DevOps ?
3.Etude de l’existant
3.1. Fonctionnement actuel
3.2. Critique de l’existant
4.Solution proposée
5.Démarche adoptée
5.1. Méthode adopté
5.2. Planification du projet
Conclusion
Chapitre 2: Etude comparative des outils DevOps
Introduction
1.Démarche de l’étude comparative
2.Outils de gestion de code source
2.1. Choix des critères
2.2. Analyse
2.3. Comparaison et synthèse
3.Outils d’intégration continue
3.1. Choix des critères
3.2. Analyse
3.3. Comparaison et synthèse
4.Outils de qualimétrie logiciels
4.1. Choix des critères
4.2. Analyse
4.3. Comparaison et synthèse
5.Outils de gestion de dépôt d’objets binaires
5.1. Choix des critères
5.2. Analyse
5.3. Comparaison et synthèse
6.Outils de gestion de configuration et automatisation
6.1. Choix des critères
6.2. Analyse
6.3. Comparaison et synthèse
7.Synthèse et choix
Conclusion
Chapitre 3: Analyse et Conception
Introduction
1.Objectifs du projet
2.Analyse des besoins
2.1. Besoins fonctionnels
2.2. Besoins non fonctionnels
Identification des acteurs
3.Cas d’utilisation global du pipeline
4.Architecture physique globale du pipeline
5.Architecture physique des environnements du projet AMC
6.1. Architecture Déploiement Hybris
6.2. Environnement d’intégration
6.3. Environnement de test
6.4. Environnement de préparation et production
Conclusion
Chapitre 4 : Réalisation
Introduction
1.Mise en place du pipeline
1.1. GitLab
1.2. Jenkins
1.3. SonarQube
1.4. Nexus
1.5. Ansible
2.Tâche pipeline dans Jenkins
2.1. Pipeline as Code
2.1. Jenkinsfile
2.2. Jenkinsfile Projet AMC
3.Gestion de configuration et Automatisation déploiement avec Ansible
3.1. Architecture Ansible
3.2. Automatisation Déploiement SAP Hybris e-commerce plateforme
3.3. Gestion de configuration des environnements
Conclusion
Conclusion Générale
Bibliographie et Webographie