Dans ce dernier article sur l’industrialisation des développements réalisés avec le SharePoint Framework, nous allons voir quelques fonctionnalités plus avancées.

1. Mise en place d'une build dans Visual Studio Online pour les applications SPFx
2. Mise en place d'une release dans VSO pour les applications SPFx
3. Scénarios et paramétrage avancés

Si dans les 2 précédents billets nous avions abordé le déploiement automatisé dans le cycle de développement, avec un environnement d’intégration continue pour les tests, nous allons cette fois-ci nous occuper de l’environnement de recette (ou préprod) et production.

Objectifs

• Surcharger les paramétrages de développement afin d’être certain de notre déploiement (i.e. ne pas réutiliser de configuration provenant des développeurs)
• Déployer la solution dans plusieurs environnements SharePoint (collections de site) 

Paramétrage de la build et de l’emplacement des ressources

Variables et options

Quelques variables vont être déclarées pour adapter notre build :

• cdnBasePath : URL du CDN 
• cdnAzureAccount : compte du blob storage associé au CDN
• cdnAccessKey : la clé d'accès au blob storage pour les accès en écriture 
• packageName : nom du package (*.sppkg)
• packageId : ID unique du package

Remarque : nous devons respécifier le nom du package et son identifiant étant donné que nous n'avons qu'un catalogue principal pour les applications. Cependant, avec la mise à disposition de catalogues par collection, cette approche pourra être adaptée / revue.

Côté options, un numéro de build personnalisé va permettre d’être réutilisé comme version du package. Cela nous permettra de faire le lien entre ce qui est disponible sur le site et son code source. Il est évidemment possible de choisir tout à fait autre chose comme numéro de version, comme par exemple de définir comme variable modifiable au moment de lancer la build, à vous de voir ce qui correspond au mieux à vos process. Pour ma part, j’ai choisi d’utiliser l’année, le mois en cours et la révision:

Modification des actions

Afin de personnaliser la solution, nous allons rajouter 3 tâches PowerShell après la tâche de mise à jour de nos packages npm :

• La première va nous servir à mettre à jour le CDN cible
• La deuxième à configurer le blob Azure dans lequel nous déploierons les ressources
• La troisième à changer le nom et l’identifiant de notre package, ainsi que son numéro de version .

 Mise à jour du manifest

Notre première tâche va donc s'occuper de mettre à jour le manifest avec le bon CDN. Nous tirons partie de la facilité de manipulation du JSON via les cmdts PowerShell Convert(From/To)-Json

Mise à jour des paramètres de déploiement Azure

Même approche, cette fois-ci on modifie les informations pour la publication dans le blob storage Azure.

Mise à jour des informations concernant le package

Enfin, ici toujours la même technique, cette fois-ci pour paramétrer notre solution. Il faudra bien évidemment le faire avant nos tâches de compilation/packaging pour en profiter !

Déploiement sur les environnements

Maintenant que notre build est prête, vous pourrez reprendre la même configuration que celle décrite dans l’article précédent, à la différence des points suivants :

• La définition de plusieurs environnements (recette, preprod, prod)
• La mise en place de variables propres à chacun de ces environnements

Il est possible évidemment de configurer des conditions de pre ou post-déploiement pour savoir qui validera le passage à l’environnement suivant.

Ensuite, côté variables, il suffira de spécifier correctement les valeurs pour chacun des environnement en sélectionnant le scope adéquat pour la variable siteUrl:

A vous de jouer maintenant pour maîtriser votre chaîne de déploiement de A à Z pour tous vos développements réalisés avec le SharePoint Framework !