Blog ACENSI
Réunion noir et blanc

Qu'est-ce que le DevOps ?

Les méthodes de projets Agile sont devenues la norme et de nombreuses entreprises se sont tournées vers cette approche. Cependant, bien que beaucoup se revendiquent Agile, il s’agit souvent de méthodes dérivées, qui n’appliquent pas toujours les principes à la règle.
Depuis quelques années est apparu un nouveau concept, fortement lié à l’application de méthodes agiles, il s’agit du DevOps.

Comment définir ce terme ?
DevOps est en réalité la contraction de deux mots. On parle de Développement et Operations (ou exploitation en français).
C’est un ensemble de pratiques qui permettent de rapprocher les développeurs d’applications et les exploitants. Cela a pour but d’obtenir une meilleure cohésion entre les deux parties, afin d’obtenir un résultat plus efficace, plus rapide et plus stable.
Il peut également s’agir de développeurs qui auront également la compétence de travailler sur la partie du déploiement, ce qui est de plus en plus rendu possible avec les technologies Cloud et gestionnaire de sources. En effet, les entreprises recherchent souvent et de plus en plus des profils polyvalents.
Il s’agit en fait d’une méthodologie, ou même plus, d’une culture, au même titre que l’Agile. On associe le développement à toute la partie Infrastructure. Le but étant de livrer des applications à un rythme soutenu et efficace.

Quelle est son origine ?
Le nom de DevOps a été introduit publiquement pour la première fois en 2008 lors de l’Agile Toronto Conference par Patrick Debois, consultant IT indépendant, et Andrew Shafer lors de leur conférence « Agile Infrastructure ». Ce terme et cette méthodologie ont par la suite été à maintes reprises réutilisés, notamment durant les DevOpsDays.

Outre le nom, l’origine de cette méthodologie serait née entre 2007 et 2008.
Dans les projets utilisant un cycle en V classique, les demandes sont claires et les exigences sont bien définies. A une phase de développement, sera suivi le déploiement du code sur les environnements concernés. Les rôles sont bien dissociés, mais le temps pris par ces opérations est assez long.
Avec le modèle Agile, ces problèmes de temps sont résolus. Les applications doivent être mises en place rapidement, et doivent pouvoir être modifiées et adaptées de manière efficaces. Les demandes et exigences peuvent rapidement évoluer, et les développeurs doivent facilement s’adapter.
Cependant, cette réaction ne concerne pas seulement les développeurs. Il faut également pouvoir déployer les modifications rapidement et de façons souples.
C’est ce qui a conduit à la naissance de cette méthodologie, où l’ensemble des intervenants doit pouvoir communiquer et travailler ensemble, pour que les applications soient le plus souples possibles.
Le Cloud et les Gestionnaires de Sources ont particulièrement accélérer la mise en place de DevOps et contribuent de plus en plus à la séparation des deux « silos ».

Concrètement de quoi parle-t-on ?
Prenons une entreprise bancaire, qui doit réaliser un projet réglementaire à mettre en place dans un délai rapide. Il faut alors pour une application, modifier le code, réaliser les tests et implémenter la solution jusqu’à l’environnement de production. Il faut alors gérer les ressources du côté développement ainsi que les ressources au niveau des exploitants. La coordination peut alors être longue et la communication ne passe pas forcément très bien.
On cherche alors avec le DevOps à faire en sorte que les deux équipes ne soient plus isolées. Il est alors fréquent qu’elles soient regroupées en une seule équipe.
Bien plus qu’une fusion d’équipe, il s’agit également d’un ensemble de bonnes pratiques indispensables à la mise en place de cette méthodologie.

Scham Agile
Le DevOps est fortement lié à la méthodologie Agile.
En effet, comme le montre le logo du DevOps (le symbole infini), il s’agit de runs complets, comme en Agile, mais incluant toute la partie de l’infrastructure. Il s’agit d’une activité continue, incluant des cycles constants comprenant :

  • La demande et le code généré
  • Le build de la solution
  • Les tests de cette incrémentation
  • Le déploiement de l’application (partie jaune)

Quelles sont ces « bonnes pratiques » ?
Dans la méthodologie DevOps, plusieurs notions sont importantes telles que l’intégration et la livraison continue,  les tests unitaires ou encore la communication.

  • Intégration Continue : C’est une méthode de développement visant à intégrer les développements de manière régulière sur un système de contrôle de versions comme Git. Le but est de pouvoir incorporer de nouvelles fonctionnalités, facilement. Les sources passent les tests unitaires avant envoi et peuvent alors être testés de façons récurrentes.
  • Livraison Continue : Etroitement liée à l’intégration continue, il s’agit ici de mettre en place un processus de tests et de déploiement normalisé pour limiter les erreurs sur l’environnement final. Cela consiste notamment à implémenter des tests unitaires exécutés sur l’environnement du développeur mais également lors de la génération des builds. Cela permet notamment de faciliter l’envoi des modifications sur un environnement pour les développeurs.

En résumé, il est conseillé de faire plus de livraisons, mais celles-ci sont de ce fait plus fiables et plus stables, notamment avec la mise en place de pratiques de tests telles que le TDD (Test Driven Developpement).

  • La communication est l’un des piliers essentiels du DevOps

Le processus de livraison implique une étroite collaboration entre les développeurs et les exploitants. Il est important de se servir d’outils tels que les systèmes de suivi, des wikis qui indiqueront les processus ou encore les messageries instantanées pour fluidifier les échanges.

Vocabulaire
Silo d’information :
Il s’agit de deux ou plusieurs entités au sein d’une entreprise qui ont des difficultés à communiquer, notamment lorsqu’elles ne souhaitent pas travailler de façons étroitement liées ou si l’entreprise favorise les cloisonnements.

TDD (Test Driven Developpement) :
Méthode de développement qui consiste à écrire son code de façon itérative. Il est en effet imposé d’écrire le test avant de commencer réellement à coder. On parle des 3A : Arrange, Act & Assert (Arranger, Agir et Affirmer).

Pourquoi ce blog ?

Pour permettre à nos consultants et experts techniques de partager leurs connaissances et retours d’expérience autour des sujets qui les passionnent. Ce blog, intégralement écrit par eux, a pour vocation d’être un véritable lieu d’échanges et d’apprentissage.

Alors n’hésitez pas à commenter nos articles pour rejoindre la conversation !

Une suggestion ?

Si vous avez des idées pour améliorer ce blog, nous sommes à l’écoute de vos remarques. Vous pouvez nous écrire via le formulaire de contact qui se trouve en bas de page.

Bonne visite !