STOCKAGE AZURE: STERING VS. production

Pas vraiment une réponse, mais j'avais besoin de plus de caractères que ceux autorisés dans les commentaires :)

Je traite également du même problème. Avoir des comptes de stockage et un serveur de base de données séparés est la voie à suivre, mais le défi consiste à choisir un compte de stockage / base de données approprié à partir de votre fichier de configuration, car vous pourriez déployer votre code dans l'environnement de mise en scène ou de production. La classe RoleInstance n'a pas le moyen de faire la distinction entre la mise en scène et la production.

Seule l'option que vous ne vous reste que d'appeler l'API de gestion de service et de déterminer quel compte de stockage / base de données à choisir. Ajoutez une complication de plus à cette équation est lorsque vous faites un échange VIP et tout à coup votre emplacement de stockage devient une fente de production (et inversement) et vous devez désormais basculer vos chaînes de compte de stockage / de base de données basées sur le nouvel environnement.

Je serais très intéressé à entendre ce que font les autres personnes.

Voici comment je gère mes environnements de production / acceptation / test (note que je n'utilise pas le mot mise en scène ). Pour chaque environnement, je crée ce qui suit (selon le projet):

• Service Cloud
• compte de stockage
• Server SQL Azure + Database
• Appfabric (ACS, ...) Espace de noms
• Machines virtuelles

  Alors supposons que j'ai une application appelée myApp , alors mes environnements ressembleraient à ceci:

  • production
    • Service Cloud: myApp-prod .cloupp.net
    • Compte de stockage: myApp-prod
    • SQL Azure Server contenant 1 base de données: MyApp
    • acceptation
      • Service Cloud: myApp-acce .cloupp.net
      • Compte de stockage: MyApp-ACCE
      • SQL AZURE Server contenant 1 base de données: myappacce
      • test
        • ...

          Ainsi, tous les environnements ont une version de l'application exécutée dans le logement de déploiement de production. Je n'utilise que la fente de déploiement de la stadification chaque fois que je veux faire un swap VIP pour mon environnement de production (notez la différence entre l'emplacement de déploiement de production et l'environnement de production).

          Il y a quelques avantages à cette approche où vous avez des composants dédiés (tels que des comptes de stockage) par environnement:

          • Il est facile de tester de nouvelles communiqués sans avoir un impact sur la demande réelle.
          • Vous pouvez avoir une sécurité différente par environnement (par exemple, tous les développeurs ont accès aux clés du compte de stockage de test)
          • Si vous testez votre application, vous pouvez travailler avec des URL réelles + SSL au lieu de cette URL longue et laid de stadification.
          • Il est facile de tester l'intégration avec ACS car chaque environnement aura son espace de noms dédié.
          • Utilisation de Visual Studio Vous pouvez facilement gérer les paramètres par environnement.
          • Et le dernier mais surtout, vous devez savoir que les objectifs d'évolutivité du stockage de Windows Azure s'appliquent au niveau de compte de stockage. Cela signifie que si vous utilisez un seul compte de stockage pour tous vos environnements, vous réduisez peut-être les performances de votre application en production, car vous effectuez des tests de stress sur l'application dans la mise en scène. Si vous utilisez un compte de stockage par environnement, vous n'aurez pas d'impact sur les autres environnements lorsque vous faites quelque chose.