I think the structure of SharePoint is naturally « DevOps oriented ». Actions to create web applications and configure services through a web interface is a DevOps philosophy ! On standard .NET environnements, such actions require interventions on servers, but SharePoint does this « out-of-the-box ».
But the work of DevOps in a SharePoint environment is not limited to that. In the case of a SharePoint farm hosting several applications, how to ensure that a solution deployment does not impact non-concerned applications ? How to be sure that an application will not be broken by an undisciplined neighbor ?
Because SharePoint is a complex service, the traditional tools of production operators are not sufficient to watch a farm. And on the other hand, development teams should not have to worry about server scalability !
This is the role of DevOps : Being the bridge between developers and production, while maintaining a consistent chain of delivery.
In a future post I will talk about the tools available to the « DevOps SharePoint ».
This is my view about what a « DevOps SharePoint » shoud be :
Traduction française :
Je pense que la structure même de SharePoint est orientée DevOps. Les actions de création d’applications web et de configuration de services au travers d’une interface web est une philosophie DevOps ! Ce genre d’actions nécessiteraient des interventions sur les serveurs, mais ici c’est SharePoint qui contrôle cela « out-of-the-box ».
Mais le travail du DevOps dans un environnement SharePoint ne se limite pas à cela. Dans le cas d’une ferme SharePoint qui hébergeraient plusieurs applications autonomes, comment garantir qu’un déploiement de solution n’impacte pas des applications non concernées ? Comment être sûr qu’une application ne soit pas impactée par le développement du voisin ?
Parce que SharePoint est un service complexe, les outils classiques des opérateurs / exploitants de production ne suffisent pas à gérer une ferme. Mais d’un autre côté, les équipes de développement n’ont pas à se soucier de l’évolutivité (scalability) des serveurs !
C’est là le rôle du DevOps : Faire le pont entre dev et prod, tout en maintenant une chaine de livraison cohérente.
Dans un prochain post je parlerais des outils à disposition du « DevOps SharePoint ».
Catégorie : DevOps
DevOps, ou comment nommer l'innommable.
Le métier de DevOps est de réconcilier les développeurs et les exploitants.
Les exploitants de production gèrent leurs serveurs avec toute l’affection qu’une mère porte à sa couvée. On surveille, on s’inquiète. Pas trop de température ? Pourquoi les fichiers de logs grossissent ? Y aurait pas comme une pointe de consommation de CPU là ?
Quant aux développeurs, voilà une bande d’hystériques* toujours à l’affût du dernier framework à la mode, prêts à déployer n’importe quelle fonctionnalité à peine testée sur les beaux serveurs clusterisés qui n’avaient rien demandé.
Bref, on oppose stabilité et changement. Deux politiques contradictoires qui doivent pourtant collaborer étroitement !
Quoi de plus frustrant qu’une gestion de projet agile s’il elle se casse les dents au moment de la mise en prod ?
Mais voici le DevOps ! Celui qui va faciliter les mises en prod, fluidifier les processus, apaiser les craintes.
Il intervient dans la mise en place des processus suivants – que chaque adorateur de l’agilité reconnaîtra :
- L’intégration continue : Déploiements réguliers sur les serveurs d’intégration.
- La livraison continue : Déploiements réguliers de builds vers la recette, puis pré-prod et prod.
Et le DevOps intervient aussi dans la mise à disposition d’outils « passerelles » entre ces différentes plateformes.
Pourquoi je parle de tout cela ? Parce qu’il s’agit de ma mission actuelle. Difficile à nommer au départ (admin ? dev ? AMOE ?), elle peut peut enfin être qualifiée en « DevOps ».
Plus qu’un terme à la mode, les équipes DevOps sont une brique essentielle des grandes entreprises IT telle que Google, qui peuvent rapidement mettre en place de nouvelles fonctionnalités dans leur services.
Sources : Article sur 01.net, DevOpsDays
*Humour