Qu'est-ce qu'une stratégie Develop-test-deploy recommandée pour Azure?

Question

Nous sommes nouveaux sur Azure et nous allons déployer notre première application dans les prochains jours. Je me demandais simplement si nous devions mettre en place un processus de sélection plus clair pour les essais et les déploiements et comment le rendre plus rentable.

C'est le processus que je considérais -

1.Mettre sur tissu Dev locale

1. Maintenir un serveur de construction commune qui héberge également le contrôle des sources (nous utilisons TFS pour les deux)

2. Utilisez le serveur de build pour les tests locaux qui alimente les bogues au développement

3. ont un compte d'azur séparé pour le test de l'environnement ing - Test-passé builds seront déployés à ce compte et utilisé pour l'environnement test

4. Une fois que les problèmes sont résolus et les tests passent, déployer la même construction pour le compte de production (directement à partir du serveur de build, je ne pouvais pas penser d'une façon de passer d'essai d'azur à la production d'azur)

Quelques points que je vais devoir prendre soin de -

1. les données devront être reproduites de la production à tester les serveurs pour les tests pour être efficace

2. activités de construction seront être automatisés pour réduire les erreurs manuelles (en particulier changer les paramètres liés à compte comme les clés)

Avez-vous les gars c'est bien? Ou y a-t-il des failles dans cela? Je voulais que le compte de test et le compte de prod soient séparés afin que les informations de sécurité de notre prod puissent être conservées uniquement avec le personnel opérationnel clé. C'est en quelque sorte ce qui est recommandé dans l'un des blogs de Microsoft, mais je voulais le faire avancer grâce à une équipe d'experts. Merci d'avance.

Answer 1

Cela dépend de la méthodologie. Si vous effectuez des itérations, gardez les tests et les comptes de production séparés, en ne faisant la promotion de la publication qu'après le test. Important: vous souhaiterez peut-être commencer à développer sur le tissu azure dès que possible (ou au moins d'utiliser le compte de stockage azure dans le cloud), puisque Dev et les tissus réels sont trop différents à ce stade. Il y a un quelques bizarreries qui peuvent vous rendre la vie plus difficile si vous comptez entièrement sur le tissu de développement et de stockage.

Si vous êtes en développement rapide (c.-à-d.: déployer des fonctionnalités stables dès qu'elles sont stables et réussir des tests unitaires), il n'y a pas de besoin explicite pour un seul compte de test (bien que certains développeurs ou prototypes aient besoin de comptes séparés par cas). Notez que vous pouvez vouloir automatiser le processus de déploiement d'une manière ou d'une autre dans ce cas (15 minutes à déployer est long) en utilisant des scripts PowerShell ou un gestionnaire de déploiement qui télécharge simplement des binaires sur le nouveau domaine d'application.

Answer 2

Vous n'avez pas besoin d'un compte Azure distinct. Au lieu de cela, vous déployez votre projet azure nouvellement construit dans le déploiement de transfert de votre compte azure, effectuez un test par rapport à celui-ci, puis échangez vos déploiements de mise en scène et de production azure.

Une chose que vous ne voulez jamais faire est de déployer un projet directement dans votre déploiement de production azure. J'ai vu le processus prendre plus de 10 minutes pour terminer et pendant ce temps votre application sera hors ligne. Le déploiement du déploiement intermédiaire dans le déploiement de déploiement de production est sensiblement plus rapide et ne devrait prendre votre application que pendant 10 à 20 secondes.