Devops est le mouvement qui vise à réunir les équipes IT, en particulier les équipes de développement et des opérations, autour d'un objectif commun : améliorer la performance de l'organisation IT au service du métier. Cet article a pour but de démontrer la puissance de ce mouvement et les premières étapes pour adopter la culture Devops sur vos projets Symfony.
La vitesse est la clef du succès dans l'économie digitale. Ce constat est particulièrement visible dans le monde des Start-ups, où les premiers arrivés sur un marché sont les seuls qui survivent. Mais c'est aussi valable dans les organisations plus traditionnelles où les clients attendent toujours plus de réactivité, portée par les nouvelles technologies. Comme le démontre le livre de Jason Jennings et Laurence Haughton, ce ne sont plus les gros qui mangent les petits mais les rapides qui mangent les lents.
Souvent le département technique est le goulot d'étranglement qui ralentit l'entreprise : la complexité des projets IT et les risques associés font qu'entre l'idée et son déploiement effectif il peut se passer plusieurs mois. Les méthodes agiles sont une réponse à ce problème. Pour aller plus vite, ces méthodes cherchent à révolutionner l'organisation à l'aide de principes simples :
Mais dans une méthode agile comme Scrum, on peut rapidement se retrouver dans une illusion de vitesse : il ne suffit pas d'itérer vite si ces itérations ne sont pas mises aussi rapidement en production. Et c'est effectivement ce qui se passe dans beaucoup d'organisations, où des équipes de développement qui ont adopté l'agilité se retrouvent à développer très rapidement des évolutions... qui s'empilent devant le département des opérations, ceux qui ont en charge de les mettre en production. En effet, les enjeux sur un projet informatique sont nombreux, et les développeurs oublient souvent ceux qui concernent la production :
Si l'équipe de développement ne s'en est pas préoccupée dans son illusion de rapidité, les évolutions ne peuvent pas aller en production telles quelles et l'organisation peut alors perdre plusieurs mois... C'est ce qu'on constate dans toutes les grandes organisations traditionnelles mais aussi dans beaucoup de startups.
Le mot Devops est apparu en 2009 sur le blog de Patrick Debois et fédère depuis tous ceux qui s'intéressent à l'agilité au sens large, du développement aux opérations. L'idée principale est que toute l'organisation IT travaille en équipe, en particulier les développeurs avec les opérations, avec un but commun : la performance de l'organisation technique au service du métier. Le mouvement Devops se penche sur trois domaines :
Devops se retrouve souvent associé à des outils de déploiement continu et de l'approvisionnement (le "provisioning"). Il est impossible pourtant d'être Devops si on ignore la partie humaine qui est au coeur du problème. Les objectifs locaux sont opposés : les équipes de développement doivent apporter rapidement des évolutions alors que les équipes d'opérations doivent garantir la stabilité des systèmes en production. C'est à ce problème que l'on s'attaque, et les outils ne sont qu'une arme parmi d'autres pour réussir à faire travailler ensemble ces équipes naturellement en conflit.
Il est facile aujourd'hui d'avoir des informations sur l'impact qu'a la culture Devops dans les organisations qui l'ont adoptée. On trouve de nombreux témoignages des leaders Devops (Etsy, Flickr, Amazon, Netflix, etc.) sur leurs blogs techniques ou à des conférences comme Velocity. Il existe aussi des études, dont une réalisée en 2013 par PuppetLabs et IT Revolution Press auprès de 4000 ingénieurs devs et ops. Les chiffres sont bluffants ! Les organisations qui disent avoir adopté Devops depuis plus d'un an :
(Tous les résultats sont dans l'étude de PuppetLabs)
La question n'est donc pas s'il faut adopter Devops mais comment l'adopter.
Dans la majorité des organisations IT, même de petite taille, l’équipe de développement est distincte de l’équipe de production et c’est l’équipe de production qui cumule le plus d’expérience.
L’équipe de développement, plus junior en âge et moins aguerrie sur l’ensemble du cycle d’un projet IT, est la moins autonome face aux problèmes inattendus. C’est donc par les devs que nous allons commencer à introduire les bonnes pratiques Devops.
Avant d'introduire des bonnes pratiques ops dans l'équipe de développement, une première étape est déjà d'adopter de bonnes pratiques de développement. Les points suivants sont un pré-requis :
Heureusement dans la communauté Symfony, ces bonnes pratiques de développement sont déjà répandues.
Attention cependant à ne pas surestimer son niveau : avec ces bonnes pratiques on n'en est encore qu'au stade du développeur adolescent.
Il est étonnant de constater que la principale différence entre un développeur à l'aise sur la partie opération et un développeur qui en a peur est simplement... l'expérience d'hébergement sur un serveur souvent à titre personnel. Cela peut paraitre évident qu'il faille un terrain de jeu pour apprendre, pourtant beaucoup de développeurs ne possèdent pas de serveur dédié et je n'ai pas rencontré d'organisations qui en fournissait un à titre de bac à sable d'entrainement.
Hors c'est une étape incontournable ! Et il n'est pas très couteux aujourd'hui de s'y mettre. En particulier Amazon propose un serveur EC2 gratuit pendant un an et Online.net un serveur dédié à 10€HT par mois donc n'hésitez pas ! Bien sûr on parle ici de serveurs Linux...
Une fois qu'on a passé l'étape indispensable d'avoir fait ses armes soit-même sur un serveur Linux, il faut commencer à adopter des bonnes pratiques qui accélèrent le flux des besoins métiers de l'expression à la production.
Les fréquences de déploiement revendiquées par les leaders du mouvement Devops sont beaucoup trop élevées pour permettre plus que quelques minutes d’intervention humaine. Si Netflix ou Etsy déploient plus de 30 fois par jour, ou qu’Amazon déploie en moyenne toutes les 11 secondes sur des dizaines de milliers de serveur, c’est parce que chaque déploiement est entièrement automatisé.
À l'échelle d'un projet Symfony standard, les deux principaux outils pour automatiser le déploiement sont :
Capifony, comme son nom l'indique est devenu le standard de la communauté Symfony, l'article de demain l'approfondira plus en détails.
Capifony permet d'automatiser très facilement à l'aide d'un fichier de configuration le déploiement. Mais Capifony a l'inconvénient de ses qualités : c'est un outil très magique qui peut devenir une boîte noire pour le développeur junior. C'est sur ce point que Fabric est intéressant car beaucoup plus basique : on se contente ici de scripter les commandes shell qu'on aurait executées sur le serveur. C'est potentiellement plus pédagogique si l'on cherche à diffuser largement le savoir autour des problématiques de production.
Voici un exemple de script de déploiement automatisé Fabric, qui s'exécute avec un simple fab deploy :
from time import strftime
from fabric.api import *
from fabric.contrib.files import exists
project_name = 'theodo-fr'
env.roledefs = {
'prod': ['prodserver'],
'preprod': ['preprodserver']
}
env.use_ssh_config = True
path = {
'prod': '/theodo/v3.theodo.fr',
'preprod': '/theodo/preprod.theodo.fr'
}
def theodo(command):
return sudo(command, user='theodo')
@roles('preprod')
def checkout_project(tag):
with cd(path[_getrole()]):
if not exists(path[_getrole()] + '/.git', use_sudo=True):
theodo('git clone --recursive git@github.com:theodo/theodo-fr.git .')
theodo('git fetch')
theodo('git fetch origin --tags')
theodo('git checkout ' + tag)
@roles('preprod')
def deploy():
tag = "%s/%s" % (_getrole(), strftime("%Y/%m-%d-%H-%M-%S"))
local('git tag -a %s -m "%s"' % (tag, _getrole()))
local('git push --tags')
checkout_project(tag)
def _getrole():
for role in env.roledefs:
if env.host_string in env.roledefs[role]:
return role
raise Exception('Role not found')
Une fois le déploiement automatisé, il faut réussir à vaincre la peur de déployer très souvent. C'est le rôle du monitoring qui, s'il est bien pensé, vous alertera à la moindre erreur et vous permettra de réagir vite. En effet, le principe "Better ask for forgiveness than permission" accélère beaucoup une organisation... mais n'est durable qu'à condition :
Ce n'est pas un hasard si StatsD, un outil de monitoring très populaire a été créé par Etsy, l'un des leaders du mouvement Devops. Une implémentation de Statsd sur un projet Symfony est décrite par Tristan Bessoussa.
Mais il existe encore plus simple aujourd'hui avec des solutions SaaS comme NewRelic et AppsDynamics. NewRelic intègre depuis très récemment un support natif Symfony2 encore assez basique mais prometteur.
Ces applications permettent, non seulement d'avoir instantanément des informations critiques de votre application sans effort, mais elles peuvent aussi alerter en cas d'augmentation du nombre d'erreurs. Indispensable pour vérifier que le dernier déploiement n'a pas eu d'impact négatif !
Bien sûr il est possible de détecter une grande partie des erreurs avant la mise en production. C'est le role de l'intégration continue qui lance l'ensemble des tests unitaires et fonctionnels à chaque commit.
Le pré-requis, comme annoncé précédemment, est l'écriture de tests unitaires et fonctionnels. À titre d'exemple Etsy avait en 2011 plus de 7000 tests. Un bon départ pour commencer est le chapitre sur les tests de la documentation Symfony. Pour aller plus loin, deux sujets souvent épineux quand on commence à faire beaucoup de tests unitaires et fonctionnels :
Pour mettre en place un système d'intégration continue et automatiser le lancement des tests, Jenkins est l'outil standard. Il permet d'avoir un tableau de bord très complet sur les métriques du projet :
Un article de blog assez complet détaille la configuration de Jenkins pour un projet Symfony.
Des solutions alternatives existent en SaaS qui permettent d'éviter toutes les étapes d'installation. L'un des premiers est Travis-CI, qui s'est rapidement rapproché de la communauté Symfony. Travis peut s'intégrer avec CoverAlls pour offrir en plus la couverture de code.
Le point à retenir est que le bon fonctionnement de l'intégration continue doit être la responsabilité des développeurs. L'existence de solutions SaaS qui rendent la maintenance de l'"usine de développement" triviale ne laisse plus d'excuses.
Un dernier élément important pour diminuer les risques est la normalisation des environnements systèmes. Développer, tester et mettre en production sur 3 environnements identiques est la meilleure façon d'éviter les bugs inexpliqués et donc les maux de tête horribles. PHP est un langage heureusement très cohérent entre les différentes plateformes, mais on est jamais à l'abri d'un bug qui n'existe qu'en 32 bits par exemple. Il n'y a aucune raison que le temps passé par l'application en développement, en testing et en recette soit dans un environnement qui ne garantisse pas la reproductibilité des erreurs.
Pour cela la solution standard est Vagrant. C'est un outil qui permet de gérer très facilement la configuration d'une machine virtuelle propre à son projet. Paul Seiffert maintient une configuration Vagrant qu'il utilise sur ses projets PHP qui est un bon départ pour démarrer son utilisation de Vagrant.
Un point important, pour ne pas être déçu par les performances de Vagrant, est d'optimiser son projet Symfony2 pour Vagrant. Les quelques astuces décrites par Benjamin Eberlei sur son blog permettent de gagner un facteur 5 sur des requêtes Symfony2 en environnement de développement. Indispensables !
Automatiser le déploiement permet d'accélérer techniquement la mise en production. Le monitoring, l'intégration continue et la normalisation des environnements permettent de diminuer les risques et donc d'accélérer concrètement dans une organisation les étapes du besoin jusqu'à la production.
Les étapes abordées ne concernent cependant que l'équipe de développement pour l'instant. La culture Devops s'étend bien au-delà et beaucoup d'autres étapes sont nécessaires, dont beaucoup à présent côté équipe de production. Ces étapes concernent tous les projets webs et sont agnostiques de l'utilisation de Symfony ou non :
Et l'adoption Devops ne s'arrête pas là, car avant toute chose, l'amélioration continue est un pilier de la culture Devops. Toutes ces étapes doivent être suivies dans cette logique, c'est à dire :
Pour aller plus loin, cet article est issu de ma conférence The Devops Wonder au Symfony Live Berlin. La présentation approfondit les étapes évoquées en conclusion.
Ensuite le plus efficace pour explorer ce sujet encore très jeune est d'échanger avec les passionnés de Devops.
Vous nous retrouverez dans des meetups comme le meetup Paris Devops, lors des conférences DevopsDays organisées partout dans le monde ou aux Velocity Conferences. J'espère vous y rencontrer nombreux !
17 Décembre
Fabrice est co-fondateur et directeur technique de Theodo, une équipe de développement agile spécialisée sur Symfony2 et Node.js. Il est aussi directeur technique d'Allomatch, le moteur de recherche des matchs diffusés dans les bars. Cette double-casquette a permis d'acquérir une expérience unique dans la maintenance et l'évolution d'applications PHP à grande échelle, qui a été la clef dans son implication dans le mouvement Devops dès 2010.