VSTS : Ségrégation d’environnements dans les Variable Groups

Vous avez implémenté une architecture Micro-Services sur Azure ou on premises et vous vous demandez comment vous allez faire pour centraliser la configuration de vos différents services selon différents environnements (DEV, TEST, PROD, etc.). Cet article pourra vous aider à répondre à vos questions, suivez-moi !

Variable Groups dans VSTS

Comme vous le savez, les portails VSTS/TFS disposent d’une fonctionnalité assez sympathique pour la centralisation de configurations : les “Variable Groups” ou groupe de variables en français. Cette fonctionnalité permet de définir des variables de substitution globales que vous pourrez employer dans toutes vos “Release Definitions” pour déployer vos services.

C’est simple et efficace, il vous suffit d’aller sur cette page [https://{team_project_url}/_library?itemType=VariableGroups] et de rajouter un groupe de variables en cliquant sur le bouton “+ Variable group” comme suit :

Une fois que le groupe est créé, vous pourrez le référencer dans n’importe quelle définition de release en allant sur l’onglet “Variables” de celle-ci et en cliquant sur le bouton “Link variable group” :

Pour plus d’informations sur les “Variable groups”, je vous invite à consulter la documentation officielle Microsoft.

Substitution par environnement

Maintenant, imaginez que vous avez une architecture composée de N services qui référencent tous une même librairie, chaque service possédant sa propre chaîne de delivery (Repo Git + Build definition + Release definition), il serait judicieux de placer la configuration de la librairie en question dans un groupe de variables partagé par toutes ces chaines.

Seul bémol, les groupes de variables ne gèrent pas la ségrégation d’environnement. Eh oui, malheureusement la portée d’un environnement ne dépasse pas le périmètre d’une “release definition” dans VSTS/TFS.

Que faire alors ?

“Nous trouverons un chemin… ou nous en créerons un”
Général Hannibal Barca – 212 av JC.

Vous l’aurez compris, nous allons créer nous même le mécanisme permettant d’introduire cette notion d’environnement au sein d’un groupe de variables.

L’idée est de préfixer les différentes variables d’un groupe par le nom de l’environnement cible et d’utiliser une nouvelle tâche de release VSTS qu’on déploiera nous même pour filtrer ces variables au moment du déploiement, cette dernière ne laissera passer que celles concernées par l’environnement en cours de déploiement.

Voici le code source de la tâche :

[CmdletBinding()]
param()

# For more information on the VSTS Task SDK:
# https://github.com/Microsoft/vsts-task-lib
Trace-VstsEnteringInvocation $MyInvocation
try {

	$env = Get-VstsInput -Name environment -Require
	$env = $env.ToUpper()
    Write-Host "Setting target environment to [$env]."
    			
	$searchPattern = Get-VstsInput -Name searchPattern -Require
    Write-Host "Setting search pattern to [$searchPattern]."
				
	$searchPattern =  [string]::Format($searchPattern, $env)				
	Write-Host "Consolidated search pattern : [$searchPattern]"
	
	$allVariables = Get-VstsTaskVariableInfo
	
	Write-Host "ALL VARIABLES : " $allVariables
	
	$targetVariables = $allVariables | Where { $_.Name -match "$searchPattern*"}
	Write-Host "Found ["$targetVariables.Count"] variable to substitute:"
	
	if($targetVariables.Count -gt 0)
	{
		Write-Host "Processing substitution..."
		
		foreach ($variableInfo in $targetVariables)
		{
		
			$cleanedName = $variableInfo.Name.Replace($searchPattern, '')
			
			$alreadySubstituedVariableLocally = $allVariables | Where { $_.Name -eq $cleanedName}
						
			if($alreadySubstituedVariableLocally.Count -ne 0)
			{
				Write-Host $variableInfo.Name " >> already defined on release definition level, substitution will be skipped"
			}
			else
			{			
				$variableObject = Get-VstsTaskVariable -Name $variableInfo.Name
				
				if($variableInfo.Secret -eq $true)
				{				
					Set-VstsTaskVariable -Name $cleanedName -Value $variableObject -Secret
				}
				else
				{
					Set-VstsTaskVariable -Name $cleanedName -Value $variableObject
				}
			
				Write-Host $variableInfo.Name" >> [$cleanedName]"
			}
		}
	}
	
	Write-Host "Substitution complete!"
	
    # Output the message to the log.
    Write-Host (Get-VstsInput -Name msg)
} finally {
    Trace-VstsLeavingInvocation $MyInvocation
}

Comme vous le voyez ci-dessus, cette tâche va parcourir l’ensemble des variables chargées en mémoire par le runner VSTS via la commande Get-VstsTaskVariableInfo et enlever les préfixes de l’environnement ciblé afin de permettre une substitution sélective.

Exemple de ségrégation d’environnements dans les groupes de variables

Admettons l’exemple suivant :

• Nous disposons de deux définitions de release pour le déploiement de deux web services.
• Ces web services référencent tous les deux la librairie “Serilog” qui dispose d’un paramètre de configuration pour définir le niveau minimal de verbosité : “MinimumLevel“.
• Nous souhaitons configurer nos deux services en verbosité maximale pour l’environnement de développement et en normale pour l’environnement de production.

La solution est simple et se fait en deux étapes.

D’abord l’installation de la tâche sur votre compte VSTS

1. 1. Installez NodeJs et Npm sur votre machine : https://nodejs.org/en/
   2. Installez le client VSTS (tfx) en exécutant la commande suivante : npm install -g tfx-cli
      Pour plus d’informations vous pouvez vous référez à la documentation officielle GitHub : https://github.com/Microsoft/tfs-cli
   3. Créez une clé d’accès PAT depuis votre profil de sécurité VSTS et gardez là dans un coin : https://{vsts_account}.visualstudio.com/_details/security/tokens
      
   4. Téléchargez le code source de la tâche depuis le repo GitHub (https://github.com/kheops321/vsts-vg-substitution), placez-vous dans le dossier en question et lancez une console cmd.
   5. Connectez-vous au portal VSTS en exécutant la commande suivante : tfx login –auth-type pat –service-url https://{vsts_account}.visualstudio.com/DefaultCollection

Le client tfx vous demandera votre clé PAT, vous lui fournirez alors la clé que vous avez généré précédemment.

• Exécutez maintenant la commande suivante pour installer la tâche sur votre compte VSTS : tfx build tasks upload
  tfx vous demandera alors le dossier contenant les sources, vous n’avez qu’à lui indiquer que c’est dans le même dossier en répondant par un point “.”

Pour vérifier que vous avez bien fait vos devoirs, rafraichissez votre navigateur, allez sur une de vos release définition, rajoutez une nouvelle tâche et vous devriez la trouver dans l’onglet “Deploy” comme suit :

Maintenant la configuration

1. Créez un groupe de variables nommé “Logging” et placez y deux variables “MinimumLevel” préfixées comme suit :
   
2. Référencez ce groupe de variables dans vos deux définitions de release comme suit :
   
3. Rajouter sur chaque environnement la tâche que vous avez déployé en configurant le préfixe comme vous l’auriez fait dans le groupe de variables à savoir “BlogCellenza_{0}_”
   Ce pattern permet d’éviter les conflits avec des variables externes liées à d’autres tâches, configs ou capacités VSTS. Vous pourrez comme bon vous semble changer ce pattern ou même en utiliser plusieurs pour plus de granularité.
   Important : la tâche “substitute variable group” doit se placer en première position dans le process de release.

Et voilà, tout est prêt, il ne vous reste plus qu’à tester la solution 🙂