VSTS et release management sous SharePoint - Partie 2

Le déploiement : le processus avant l’automatisation

Comme indiqué dans la partie 1 de l’article, l’approche DevOps nécessite une bonne communication avec l’IT (les opérateurs). Mais elle ne reste pas suffisante car il convient de définir un processus clair et si possible systémique.

En effet, c’est peut-être enfoncer une porte ouverte que de le dire, mais tenter d’automatiser un déploiement où systématiquement les techniques sont différentes une fois sur l’autre est peine perdue.

Ainsi, définissez le mode de déploiement, qui fait quoi et comment, sur quels serveurs, avec quels comptes… Imaginez également les procédures de validation d’un bon déploiement et de retours arrières (rollback).

Une fois que ces éléments sont listés et partagés, il est possible d’envisager une automatisation. Peut-être que certains aspects ne seront pas automatisables ou à un coût élevé ne justifiant pas l’investissement (ex : est-ce vraiment intéressant de passer 15j à automatiser une tache manuelle d’1mn qui est exécutée 1 fois par mois ?). Ce n’est pas grave, il suffira d’adapter notre processus automatique afin qu’il en tienne compte : il attendra simplement la fin de l’exécution manuelle avant de poursuivre.

Définir les environnements dans VSTS

Une fois la procédure définie et automatisable par environnements cibles, il convient de la paramétrer dans l’outil. Là encore, VSTS nous aide simplement car il nous offre la possibilité à partir de résultats de builds de les déployer en parallèle ou en séquentiel, avec ou sans validation, sur les environnements cibles.

Dans l’onglet « Release », nous créerons une nouvelle « Release ». La notion de « release » peut être assimilée au processus de génération d’une nouvelle version de votre produit et de son déploiement sur différentes machines / environnements.

Chaque Release embarque son ensemble d’environnements. Pour chaque environnement, il vous est possible de définir un ensemble d’actions à exécuter avant de passer au suivant. La logique de définition des actions est exactement la même que pour la définition d’une build. On n’est donc pas perdu.

Notez bien qu’il peut tout à fait être possible d’avoir plusieurs machines pour un même environnement.

Dans notre cas, nous avons à notre disposition un environnement d’intégration et un environnement de qualification SharePoint. Chacun dispose de ses propres machines (Serveurs d’application, Frontaux, Bases de données…). Notre processus de déploiement est assez simple : suite au build, le package est récupéré puis déployé sur le serveur d’intégration. Ensuite, un administrateur technique procède à des tests complémentaires pour valider le bon fonctionnement et la non régression technique. Une fois fait, le processus continue et le déploiement est effectué en qualification. Là, un testeur fonctionnel valide le bon comportement de l’application.

Ainsi, dans la définition VSTS de notre release, nous avons créé deux environnements « Intégration » et « Qualification ». Comme notre déploiement est d’ores et déjà scripté via du powershell, nous n’avons (en première instance) comme action que le déclanchement d’un script powershell.

powershell script

powershell script

Il ne reste plus qu’à continuer la configuration générale en faisant le lien entre notre build et la release via l’onglet « Artifacts », puis de spécifier les actions de déclanchements « Triggers » pour une exécution automatique suite au build. Les autres onglets sont intéressants pour la définition des variables et autres paramétrages comme les logiques de validation pré ou post-déploiement.

Exécuter la release

Désormais, notre release est complétement configurée. Il ne reste plus qu’à l’exécuter. Rien de plus facile, lançons la build et VSTS fait le reste. Nous sommes informés et notifiés sur l’ensemble des étapes clés. Les validateurs intermédiaires sont sollicitées pour faire avancer le déploiement sur les différents environnements et notre solution SharePoint est directement testable sur le serveur les serveurs cibles.

Point fort, la traçabilité est totale puisque chaque action est logguée et rattachée à des tickets VSTS.

Conclusion

Ainsi nous avons vu comment déployer via VSTS une solution SharePoint dans des environnements On Premise pour permettre aux différentes équipes d’intervenir et de valider au bon moment. Nous avons ainsi optimisé les charges de chacun.

A noter que nous n’avons cependant pas abordé l’ensemble des étapes d’un processus DevOps classique, comme la collecte des besoins ou les mécaniques de retour arrière (rollback). Ces derniers points étant trop importants pour être évoqués dans le présent article. De même, les éléments de détails de scripting n’ont pas été abordés.

Enfin, il faut remarquer que la mise en place d’une démarche DevOps est une conduite d’amélioration continue. Selon la maturité des équipes il est tout à fait possible (voire même conseillé) de gravir progressivement les étapes pour des résultats optimaux. Il ne reste plus qu’à vous lancer !

 

ffarre

Architecte de Solutions, SQLI Paris

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 !