Comment rouler automatiquement les mises à jour en production

Le lancement de la nouvelle version en opération de combat est toujours un événement nerveux. Surtout si le processus implique de nombreuses opérations manuelles. Le facteur humain est une chose terrible. «Ce serait bien d'automatiser ce processus» - cette idée est aussi ancienne que tout le monde informatique. Et il y a un terme pour cela - Déploiement continu. Oui, le problème est qu'il n'existe aucun moyen unique de configurer ce déploiement continu. Ce processus est en grande partie lié à la pile technologique du projet et de son environnement.

Dans cet article, je souhaite partager une expérience pratique de la configuration des mises à jour automatiques du système sans interrompre son fonctionnement pour un environnement technologique spécifique, à savoir: Application Web ASP.NET MVC + Azure SQL + Entity Framework en mode Code First, l'application est déployée dans Azure en tant que App Service et l'assemblage et le déploiement sont effectués via Azure DevOps (anciennement Visual Studio Team Services).



À première vue, tout est très simple, Azure App Service a le concept d'emplacement de déploiement - téléchargez-y la nouvelle version et allumez-la. Mais ce serait simple si le projet était basé sur un SGBD non relationnel, dans lequel il n'y a pas de schéma de données rigide. Dans ce cas, oui - seule la nouvelle version capte le trafic et le tour est joué. Mais avec un SGBD relationnel, tout est un peu plus compliqué.

Les principaux facteurs qui nous empêchent de mettre en œuvre un déploiement continu pour notre pile technologique sont les suivants:

• L'ancienne version de l'application ne peut pas fonctionner avec la nouvelle structure de base de données
• La mise à jour de la structure de la base de données peut prendre un temps considérable et n'est pas toujours possible en utilisant l'application elle-même via le mécanisme de migration automatique.

Je vais vous expliquer. Supposons que vous ayez déployé une nouvelle version dans un emplacement parallèle ou dans un centre de données de sauvegarde et démarré l'application des migrations. Supposons que nous ayons trois migrations et, horreur, deux ont roulé et la troisième est tombée. Pour le moment, rien ne se passera sur les serveurs qui fonctionnent, Entity Framework ne vérifie pas la version de chaque requête, mais vous ne pourrez probablement pas résoudre rapidement le problème. À ce moment, la charge sur l'application peut augmenter, et la plate-forme lancera une instance supplémentaire de l'application pour vous, et cela ... naturellement ne démarrera pas, car la structure de la base de données a changé. Une partie importante des utilisateurs commencera à recevoir des erreurs. Ainsi, le risque d'application automatique des migrations est grand.



Quant au deuxième point, votre migration peut contenir une sorte de commandes dont le temps d'exécution dépasse 30 secondes et la procédure standard expirera. Eh bien, en plus de ces points, personnellement, je n'aime pas le fait que lors des migrations automatiques, vous êtes obligé de mettre à niveau une partie de l'infrastructure vers une nouvelle version. Et si pour un mode avec des emplacements dans Azure ce n'est pas si effrayant, alors pour un mode avec un centre de données de sauvegarde, vous obtenez une partie de l'infrastructure avec une application notoirement inopérante. Tout est dangereux, il tirera au moment le plus inopportun.

Que faire

Commençons par les plus difficiles - avec la base de données. Il serait donc agréable de mettre à jour automatiquement la structure de la base de données pour que les anciennes versions de l'application continuent de fonctionner. De plus, il serait intéressant de prendre en compte le fait qu'il existe de telles mises à jour dans lesquelles une commande distincte peut être exécutée pendant un temps considérable, ce qui signifie que nous devons mettre à jour la base de données non pas en utilisant les mécanismes intégrés mais en exécutant un script SQL séparé. Question: comment le préparer? Vous pouvez créer ce manuel de processus. Si vous avez un rôle de gestionnaire de versions distinct dans l'équipe, vous pouvez le forcer à exécuter la commande dans Visual Studio:

update-database -script 

Elle générera un script et cette personne mettra ce script dans un dossier de projet spécifique. Mais vous devez admettre que cela est toujours gênant, d'une part, le facteur humain et, d'autre part, les difficultés inutiles s'il y avait plus d'une migration entre les versions. Ou pour une raison quelconque, une version a été ignorée sur le système cible. Nous devrons créer une sorte de jardin compliqué avec le suivi des migrations qui sont déjà là et qui doivent être lancées. C'est difficile et, surtout, c'est le même vélo qui a déjà été fabriqué dans le mécanisme de migration.

Et il sera correct d'intégrer le processus de génération et d'exécution de script dans le processus de calcul de la version. Afin de générer un script de migration, vous pouvez utiliser l'utilitaire migrate.exe, qui est inclus avec Entity Framework. J'attire votre attention sur le fait que vous avez besoin d'Entity Framework version 6.2 ou supérieure, car l'option de génération de script n'est apparue dans cet utilitaire qu'en avril 2017. L'appel d'utilité ressemble à ceci:

 migrate.exe Context.dll /connectionString="Data Source=localhost;Initial Catalog=myDB;User Id=sa;Password=myPassword;" /connectionProviderName="System.Data.SqlClient" /sc /startUpDirectory="c:\projects\MyProject\bin\Release" /verbose 

Le nom de l'assembly est indiqué où se trouve votre contexte, la chaîne de connexion à la base de données cible, le fournisseur et, très important, le répertoire de démarrage, qui contient à la fois l'assembly avec le contexte et l'assembly Entity Framework. N'expérimentez pas avec les noms du répertoire de travail, soyez plus simple. Nous sommes tombés sur le fait que migrate.exe ne pouvait pas lire le répertoire, au nom duquel il y avait des espaces et des caractères non-lettre.

Ici, il est nécessaire de faire une digression importante. Le fait est qu'après avoir exécuté la commande ci-dessus, un seul script SQL sera généré contenant toutes les commandes pour toutes les migrations qui doivent être appliquées à la base de données cible. Pour Microsoft SQL Server, ce n'est pas très bon. Le fait est que le serveur exécute les commandes sans le séparateur GO en tant que package unique et que certaines opérations ne peuvent pas être effectuées ensemble dans un package unique.

Par exemple, dans certains cas, l'ajout d'un champ à une table et la création immédiate d'un index sur cette table avec un nouveau champ ne fonctionne pas. Mais cela ne suffit pas, certaines commandes nécessitent certains paramètres d'environnement lors de l'exécution du script. Ces paramètres sont activés par défaut lorsque vous vous connectez à SQL Server via SQL Server Management Studio, mais lorsque le script est exécuté via l'utilitaire de console SQLCMD, ils doivent être définis manuellement. Pour tenir compte de tout cela, vous devrez modifier le processus de génération du script de migration avec un fichier. Pour ce faire, créez une classe supplémentaire à côté du contexte de date, qui fait tout ce dont vous avez besoin:

  public class MigrationScriptBuilder : SqlServerMigrationSqlGenerator { public override IEnumerable<MigrationStatement> Generate(IEnumerable<MigrationOperation> migrationOperations, string providerManifestToken) { var statements = base.Generate(migrationOperations, providerManifestToken); var result = new List<MigrationStatement>(); result.Add(new MigrationStatement { Sql = "SET QUOTED_IDENTIFIER ON;" }); foreach (var item in statements) { item.BatchTerminator = "GO"; result.Add(item); } return result; } } 

Et pour que Entity Framework puisse l'utiliser, enregistrez-le dans la classe Configuration, qui se trouve généralement dans le dossier Migrations:

  public Configuration() { SetSqlGenerator("System.Data.SqlClient", new MigrationScriptBuilder()); …. } 

Après cela, le script de migration résultant contiendra GO entre chaque instruction, et au début du fichier contiendra SET QUOTED_IDENTIFIER ON;

Hourra, la préparation est faite, il reste à configurer le processus lui-même. En général, dans le cadre du processus de publication dans Azure DevOps (VSTS / TFS), cela est déjà assez simple. Nous devons créer un script PowerShell comme celui-ci:

 param ( [string] [Parameter(Mandatory=$true)] $dbserver, [string] [Parameter(Mandatory=$true)] $dbname, [string] [Parameter(Mandatory=$true)] $dbserverlogin, [string] [Parameter(Mandatory=$true)] $dbserverpassword, [string] [Parameter(Mandatory=$true)] $rootPath, [string] [Parameter(Mandatory=$true)] $buildAliasName, [string] [Parameter(Mandatory=$true)] $contextFilesLocation, ) Write-Host "Generating migration script..." $fullpath="$rootPath\$buildAliasName\$contextFilesLocation" Write-Host $fullpath & "$fullpath\migrate.exe" Context.dll /connectionProviderName="System.Data.SqlClient" /connectionString="Server=tcp:$dbserver.database.windows.net,1433;Initial Catalog=$dbname;Persist Security Info=False;User ID=$dbserverlogin;Password=$dbserverpassword;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" /startUpDirectory=$fullpath /verbose /scriptFile=1.SQL Write-Host "Running migration script..." & "SQLCMD" -S "$dbserver.database.windows.net" -U $dbserverlogin@$dbserver -P $dbserverpassword -d $dbname -i 1.SQL Write-Host "====Finished with migration script====" 

Et ajoutez l'unité d'exécution de script PowerShell au processus de calcul de la version. Le bloc et ses paramètres peuvent ressembler à ceci:



La configuration de PowerShell ressemble à ceci:



Il est important de ne pas oublier d'ajouter le fichier migrate.exe au projet à partir du dossier <YourProject> /packages/EntityFramework.6.2.0/tools/ et de lui attribuer la propriété Copy Always afin que cet utilitaire soit copié dans le répertoire de sortie lors de la construction du projet et que vous puissiez y accéder dans Version Azure DevOps.

La nuance . Si votre projet utilise également WebJob lors du déploiement sur Azure App Service, l'ajout de Migrate.exe à votre projet n'est pas sûr. Nous sommes confrontés au fait que dans le dossier où votre WebJob est publié, la plateforme Azure démarre stupidement le premier fichier exe qui se présente. Et si votre WebJob coûte par ordre alphabétique plus tard migrate.exe (et nous l'avons fait), il essaie alors d'exécuter migrate.exe à la place de votre projet!

Nous avons donc appris à mettre à jour la version de la base de données en générant un script pendant le processus de publication, la chose simple est: désactiver la vérification de la version de migration, de sorte que s'il y a des échecs dans le processus d'exécution du script, l'ancienne version de notre code continue de fonctionner. Je pense qu'il n'est pas nécessaire de dire que vos migrations doivent être non destructives. C'est-à-dire les modifications apportées à la structure de la base de données ne devraient pas interférer avec les performances de la version précédente, mais mieux que les deux précédentes. Pour désactiver la vérification, il vous suffit d'ajouter le bloc suivant à Web.config:

  <entityFramework> <contexts> <context type="<full namespace for your DataContext class>, MyAssembly" disableDatabaseInitialization="true"/> </contexts> </entityFramework> 

Où l' full namespace for your DataContext class est l'espace de noms complet de votre descendant de DbContext et MyAssembly est le nom de l'assembly dans lequel se trouve votre contexte.

Et enfin, il est hautement souhaitable pour nous de nous assurer que l'application se réchauffe avant de basculer les utilisateurs vers la nouvelle version. Pour ce faire, ajoutez un bloc spécial à web.config avec des liens que votre application quitte automatiquement pendant le processus d'initialisation:

  <system.webServer> <applicationInitialization doAppInitAfterRestart="true"> <add initializationPage="/" hostName="" /> </applicationInitialization> </system.webServer> 

Vous pouvez ajouter plusieurs liens simplement en ajoutant /> Il est soutenu que dans Azure, lors du changement de créneaux, la plate-forme attend que l'application s'initialise et bascule ensuite le trafic vers la nouvelle version.

Mais qu'en est-il d'un projet sur .NET Core?

Tout est beaucoup plus simple et en même temps différent. Un script de migration peut être généré à l'aide d'outils ordinaires, mais il n'est pas basé sur l'assemblage fini, mais sur le fichier de projet. Ainsi, le script doit être formé dans le cadre du processus d'assemblage du projet et doit être inclus en tant qu'artefact d'assemblage. Dans ce cas, le script contiendra toutes les commandes de toutes les migrations depuis le début du temps. Il n'y a aucun problème à cela, car le script est idempotent, c'est-à-dire il peut être appliqué à la base cible à plusieurs reprises sans aucune conséquence. Cela a une autre conséquence utile: nous n'avons pas besoin de modifier le processus de génération de script pour séparer les commandes en packages, tout a déjà été fait pour cela.

Eh bien, en particulier, les étapes du processus ressemblent à ceci. Dans le processus de génération, ajoutez la tâche:



Nous le configurons pour générer un fichier avec des migrations:



N'oubliez pas d'ajouter un script au projet PowerShell qui effectuera la migration (décrite ci-dessus) et le fichier de migration lui-même. Par conséquent, après la construction du projet, les artefacts peuvent ressembler à ceci (en plus de l'archive réelle avec l'assembly, il existe un script PS supplémentaire et un script SQL avec migrations):



Il ne reste qu'à l'étape Release appropriée pour configurer l'exécution de ce script PowerShell de la même manière que décrit ci-dessus.

À propos de l'auteur

Pavel Kutakov est un expert des technologies cloud, un développeur et architecte de systèmes logiciels dans divers secteurs d'activité - de l'IP bancaire opérant dans le monde entier des États-Unis à la Papouasie-Nouvelle-Guinée, en passant par une solution cloud pour l'opérateur de loterie national.