Tout commence en 2003, lorsque Google recrute Ben Trenor à la tête des ingénieurs dans un environnement de production distinct de celui de développement. Ces ingénieurs endossaient un nouveau titre de poste nommé SRE (Site Reliability Engineering) dont la tâche principale était d’assurer une disponibilité élevée des services proposés par google, tout en collaborant étroitement avec les développeurs. La moindre interruption des opérations pour les clients entraînait des pertes de revenus à google, ainsi les SRE ont été les précurseurs de cette philosophie axée sur la fiabilité des infrastructures pour réduire les temps d’arrêt et augmenter la satisfaction des clients. En 2007, l’administrateur système consultant Patrick Debois était sur un projet de migration de données pour le gouvernement belge. Il était impacté par le manque de cohérence et de communication entre les développeurs et les administrateurs systèmes. En 2008, il participe à une conférence agile de Toronto organisé par le développeur Andrew Shafer qui voulait présenter un sujet qui l’inspirait: “Agile Infrastructure ». Malheureusement Patrick Debois était le seul présent dans la salle contraignant Andrew shafer d’annuler son talk. Mais cela permettra aux deux informaticiens de discuter longuement de la problématique de Patrick et ont ensuite créé “Agile system Administration Group”. En 2009, John Allspaw et Paul Hammond (je n’ai pas trouvé son profile LinkedIn ) donnent une conférence pendant le Velocity O’Reilly intitulée en français “10+ déploiements par jour : coopération Dev et Ops à Flickr” d’où ils relatent le retour d’expérience très positif issu d’une collaboration étroite entre Dev et Ops sur le projet Flick dont leur solution pour une bonne collaboration entre les Dev et les ops était d’embaucher des « Ops qui pensent comme les Devs » et des « Devs qui pensent comme les Ops ». Cela pour éviter des propos tels que: « ce n’est pas mon code, ce sont vos machines! » ou « Ce ne sont pas mes machines, mais c’est votre code! ». Il est à noter que l’équipe de développement (appelée les Dev*) a pour objectif principal de faire évoluer l’application, en ajoutant de nouvelles fonctionnalités ou en corrigeant des bugs, le plus rapidement possible. L’équipe des administrateurs systèmes (appelée Ops*) se charge de maintenir l’application en conditions opérationnelles, en garantissant la stabilité de l’application et sa qualité, en sacrifiant le coût et le temps nécessaire au déploiement d’une nouvelle version. Se plaignant sur twitter de ne pas avoir pu assister à la conférence, Patrick Dubois se voit répliquer par Paul Nasrat (je n’ai pas trouvé son profile LinkedIn ): « pourquoi n’organisez vous pas votre propre évènement velocity en Belgique? ». Quelque mois après, Patrick Dubois se décide d’organiser sa propre conférence nommée “ DevOpsDays” car trouvait “Agile Administration System” trop long. Pour annoncer cette conférence sur twitter, il utilise l’hashtag “DevOps” comme dimunitif des mots “développement” et “opérations” qui devient instantanément viral. Depuis, le mouvement évolue, se structure, les outils apparaissent et se développent. Les bonnes pratiques se partagent et de plus en plus d’entreprises rejoignent ce mouvement.