Migration de base de données et emplacements de déploiement Azure


15

Je prévois de pousser une nouvelle application Web vers un service d'application Web Azure (ancien site Web Azure). Je voudrais utiliser les emplacements de déploiement pour pouvoir tester mon déploiement avant de le pousser en production. C'est très bien tant qu'aucun changement de schéma de base de données n'est requis. Mais s'il y a un changement de schéma, je ne peux pas avoir deux versions logicielles fonctionnant sur la même version db. Étant donné que j'utilise EF Migrations, la poussée vers l'emplacement de transfert entraînerait instantanément une mise à jour de la base de données vers la dernière version.

Ma question est donc de savoir s'il existe une utilisation des emplacements de déploiement lorsqu'une migration de base de données est requise?

Comment cela se fait-il pour les grands fournisseurs de SaaS? Réalisent-ils une migration de base de données instantanément avec la nouvelle version? Cela entraînerait sûrement des temps d'arrêt.

Je ne peux penser qu'à des solutions assez complexes à ce problème, y a-t-il quelque chose de simple?


Vous n'avez donc pas de base de données de développement?
JeffO

Oui, nous avons un système de développement et d'assurance qualité. Le système décrit ci-dessus est destiné à la production.
Sam7

@ Sam7 avez-vous réussi à trouver une solution à ce problème? Acclamations
WestDiscGolf

J'ai bien peur que non. Nous testons actuellement les changements de migration dans un environnement distinct.
Sam7

@ Sam7: Je pense que vous pouvez gérer cela par un fichier .config séparé avec une propre chaîne de connexion à votre base de données. mais vous avez raison, lorsque vous vous déployez de l'étape à la production, l'avantage d'un rollback ne fonctionne plus. les modifications de la base de données s'appliqueront instantanément. je suis curieux de trouver une solution dans un avenir proche ...
Roger S.

Réponses:


3

Les versions sans interruption utilisant les emplacements Azure App Service et une seule base de données partagée par Staging and Production sont possibles, mais vous devez vous assurer que toutes les modifications de la base de données sont rétrocompatibles, de sorte que les versions actuelle et nouvelle de l'application Web puissent s'exécuter simultanément dans les emplacements de mise en scène et de production.

Quelques règles qui garantissent que cela fonctionne:

  • Toute nouvelle colonne de base de données doit pouvoir être annulée ou avoir des valeurs par défaut
  • Le changement de nom des colonnes n'est pas autorisé
  • La suppression de colonnes n'est pas autorisée

Lorsque vous devez apporter des modifications destructives, telles que renommer ou supprimer des colonnes, vous avez besoin de 2 versions pour ce faire:

  1. La nouvelle version de l'application Web devrait être publiée, ce qui supprime la dépendance sur les colonnes renommées / supprimées
  2. Une version supplémentaire est effectuée qui effectue les changements destructifs

Bien que cela semble un peu compliqué, dans la pratique, vous n'effectuerez probablement pas de changements destructeurs très souvent.


0

avez-vous regardé les éléments de configuration spécifiques à l'emplacement? Sous WebApp / Paramètres / Paramètres d'application, vous pouvez spécifier les paramètres de l'application Web, mais également définir si elle s'applique uniquement à cet emplacement.

Vous pouvez donc avoir une chaîne de connexion spécifique à l'emplacement pour votre emplacement intermédiaire et appliquer également la migration sur les emplacements de permutation.


2
Cela va à l'encontre de mon idée de faire fonctionner le site intermédiaire sur le même ensemble de données (-> base de données) que la production.
Sam7
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.