VSTS et release management sous SharePoint - Partie 1

Il est de plus en plus commun dans une approche DevOps de vouloir intégrer la notion de release management lorsque l’on délivre un produit informatique. SharePoint 2013 et ses solutions personnalisées (Farm, Sandbox ou Apps) n’échappent pas à cette dynamique moderne et agile.

Microsoft, toujours plus à l’écoute de ses clients, se propose de répondre à cette demande grâce à sa forge logicielle Visual Studio Team Services, aka VSTS (anciennement appelé Visual Studio Online). En effet, cette solution cloud offre une brique de release management très intéressante pour gérer ce type de besoin.

Ainsi, nous allons voir comment une équipe désireuse peut bénéficier de la plateforme VSTS pour exécuter une build d’intégration continue d’une solution personnalisée SharePoint 2013 et la déployer successivement dans des environnements de validation successifs.

Le contexte

Pour imager notre présentation, envisageons que nous sommes responsables de la réalisation d’une application SharePoint devant gérer les contrats de l’entreprise. Notre produit est un ensemble de solutions de type « Ferme » (Farm Solution) déployant tout à la fois de nouveaux jobs SharePoint, collections SharePoint, types de contenus …

Nous sommes dans le département « étude » de la société et nous devons déployer cette solution sur l’ensemble des fermes SharePoint gérées par l’IT. Les environnements classiques sont présents : Intégration, Pré-production et bien sûr la cible : la production.

Comme de bien entendu, chacun d’eux apporte son lot de différences face à l’environnement cible. Ainsi l’environnement d’intégration est mono-frontal et ne dispose que d’un serveur de services applicatifs exécutant l’intégralité des fonctions de recherche. L’environnement de pré-production dispose de plusieurs frontaux, de plusieurs serveurs de services et d’une ferme de recherche dédiée.

DevOps, la communication en priorité.

L’un des fondamentaux de l’agilité est la communication avant les outils. La logique DevOps suit le même principe. Ainsi, en bon développeur que nous sommes, nous avons écouté les métiers et donc normalement réalisés leurs attentes via des Users Stories. Mais nous devons régulièrement solliciter les équipes IT pour comprendre leurs contraintes (organisations physiques du réseau/machines, règles de sécurité…) et leurs attentes (scripts powershell de déploiement, structure des logs, besoin de supervision…). Ce dernier point n’est pas à exclure car indépendamment des principes d’automatisation dont nous parlerons par la suite, il nous permettra d’organiser notre code et nos scripts de livraisons de la façon la plus adaptée aux règles de déploiement de l’entreprise.

VSTS, branches et build

Fort de ces connaissances, nous avons stocké notre code source sous différentes branches dans VSTS. Nous avons une branche DEV, comportant l’ensemble du code en cours de développement et pour lequel chacun des archivages (check-in) est validé par une build d’intégration continue.

Notre branche MAIN est la branche stable, où notre Leader Technique vient régulièrement fusionner depuis la branche DEV le code lié aux tâches finalisées des développeurs. C’est depuis cette branche stable que nous souhaitons définir une build source pour notre release. Pour ce faire, nous allons profiter de notre serveur de build SharePoint.

Le serveur de build VSTS On Premise pour SharePoint

Avant de pouvoir exécuter des builds, il convient d’installer l’agent VSTS sur notre machine de build OnPremise dédiée à SharePoint. Pour se faire, rien de plus simple, dans la page « Agent Pools » du paramétrage de votre compte (cf. capture XXX), pour télécharger l’agent sur votre machine.

doc vs code

doc vs code

Une fois récupéré, dans une fenêtre d’invite de commande en mode administrateur, lancez l’outil de configuration « ConfigureAgent.cmd » et répondez simplement aux questions de paramétrage (nom de l’agent, url de la collection de site VSTS…)

Notre agent est désormais prêt à être utilisé dans les builds. Comme il est dédié à SharePoint 2013, nous allons le distinguer des autres agent en lui ajoutant un attribut (capability) spécifiant la version de SharePoint et du service pack. Ce dernier peut être pratique si nous avons plusieurs versions de SharePoint à maintenir.

agents for pool defaut

add capability

La description de la build

Le nouveau système de build de la plateforme, aka Build vNext, est simple et explicite. Pour notre besoin, la build se limite à la construction du package. Même s’il est possible de déployer via un Build, il est préférable de déporter la tâche à la brique « Release » dont c’est l’objectif principal.

Notre build est donc destinée à récupérer le code source, le compiler et le valider. Ce sont des étapes classiques et le modèle standard VSTS le supporte déjà. Nous l’utiliserons donc.

Cependant, une petite modification devra être apportée à l’étape de compilation MSBuild pour générer le package WSP (un peu l’équivalent d’un MSI) et non simplement les assemblies. Il suffit d’ajouter le paramètre /p:IsPackaging=true.

visual studio build

ajout d’un paramètre à la build solution

Notre build de génération de package de déploiement est désormais faite. Il nous reste plus qu’à passer à l’étape suivante.

 

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !