Discussion :

[sam_XIII]

Bonjour à tous,

Je suis à la recherche de conseils concernant le release management dans Azure.
J'ai trouvé des tutoriaux mais je me pose toujours quelque questions.

J'ai une solution asp.net 4 comprenant pour simplifier un projet asp.net mvc, un projet db et un projet test

J'utilise git dans visual studio online

Pour le moment j'ai un app service et une base de données sql dans azure.
J'ai fait un build qui récupère les NuGet, build, exécute un dacpac pour la db, exécute les tests de mon projet test (il y a des tests d'intégration qui attaquent la base de données) et enfin déploie l'application sur le app service.

A présent je souhaite:

Créer le build, le déployer sur un environnement "dev" dans azure, ensuite passer sur un environnement "QA", ensuite "stagging" et enfin prod

Dans mon projet web j'ai créé les différents environnements via le configuration manager et j'ai fait des transformations de web.config pour chaque environnement.

J'ai vu les releases dans visual studio online et je comprends bien que je dois passer par la pour déployer dans les différents environnement

Ce dont je ne suis pas certain :

Dans Azure :

-> est-ce que je crée 1 app service par environnement ou bien est-ce que j'utilise les slots d'un seul app service ?
-> est-ce que je crée 1 serveur sql par environnement ou bien j'utilise le même et je fait une base de donnée par environnement ?

Dans visual studio online :

- comment dois-je répartir les tâches ?
- dans le build, quelle configuration de quel environnement dois-je renseigner ?
- dans le build -> comment gérer le projet db ? je pense que le déploiement doit se faire via la release mais je ne vois pas comment changer la configuration
- pour les tests -> je dois les exécuter via les release ? mais comment changer les chaines de connexion ? il n'y a pas de fichier de transformations ?
- J'ai vu qu'il y a les test-plan aussi : est-ce que je dois les utiliser ?



Est-ce que quelq'un peut m'aider à y voir plus clair ?

Merci d'avance !

[DotNetMatt]

-> est-ce que je crée 1 app service par environnement ou bien est-ce que j'utilise les slots d'un seul app service ?

C'est plus simple d'utiliser les slots, car il y a des fonctionnalites pour "swapper" les slots entre eux (et donc la possibilite de revenir en arriere si besoin). Je pense aussi qu'au niveau facturation c'est plus avantageux (a verifier). Tu peux envisager 1 App Service par environnement si tu as des deploiements particulierement complexes, ce qui ne semble pas etre ton cas pour le moment. Donc mon avis, utilise les slots.

On voit souvent 3 a 4 environnements differents : DEV --> STAGING --> PROD ou DEV --> STAGING --> PRE-PROD --> PROD.

-> est-ce que je crée 1 serveur sql par environnement ou bien j'utilise le même et je fait une base de donnée par environnement ?

En general on utilise 1 DB par environnement. En effet en PROD on aura tendance a avoir la version stable, en staging et en DEV on sera moins stable, et avec de nouvelles fonctionnalites pas encore livrees en PROD. Souvent, les mises a jour de la DB sont liees aux mises a jour du code, donc il peut etre problematique d'avoir une version X de la DB avec une version Y du code, sauf si tu utilises des Vues et que ces Vues te garantissent une retro compatibilite... Il faut aussi prendre en compte la taille de l'equipe, plus vous etes nombreux et plus il est complique de n'utiliser qu'une seule DB. Mon avis : 1 par environnement.

En general le nombre de DB est equivalent au nombre d'environnements.

- comment dois-je répartir les tâches ?

Comme pour une build classique.

- dans le build, quelle configuration de quel environnement dois-je renseigner ?

Tu dois pointer vers le slot de DEV - ou le serveur de DEV si tu as choisi de monter une VM par environnement.

- dans le build -> comment gérer le projet db ? je pense que le déploiement doit se faire via la release mais je ne vois pas comment changer la configuration

Documentation : Deploy your database to Azure SQL Database using DACPACs. Voir aussi les liens dans le document.

- pour les tests -> je dois les exécuter via les release ? mais comment changer les chaines de connexion ? il n'y a pas de fichier de transformations ?

Je ne comprends pas trop ta question. Peux-tu aussi preciser s'il s'agit de tests unitaires et/ou de tests d'integration ?

- J'ai vu qu'il y a les test-plan aussi : est-ce que je dois les utiliser ?

Il n'y a pas d'obligation, ca depend de tes besoins. Les test plans permettent de guider les testeurs pas a pas, d'avoir un reporting sur l'avancee de la campagne de tests, et de pouvoir creer directement des tickets (bugs...) depuis les cas de test.

[sam_XIII]

Merci énormément pour ton aide !

C'est plus simple d'utiliser les slots, car il y a des fonctionnalites pour "swapper" les slots entre eux (et donc la possibilite de revenir en arriere si besoin). Je pense aussi qu'au niveau facturation c'est plus avantageux (a verifier). Tu peux envisager 1 App Service par environnement si tu as des deploiements particulierement complexes, ce qui ne semble pas etre ton cas pour le moment. Donc mon avis, utilise les slots.

On voit souvent 3 a 4 environnements differents : DEV --> STAGING --> PROD ou DEV --> STAGING --> PRE-PROD --> PROD.

Au final je suis parti sur 2 appservice avec des slots, le premier pour dev/demo et le second pour staging/prod (pour avoir une séparation entre les deux)

Je ne comprends pas trop ta question. Peux-tu aussi preciser s'il s'agit de tests unitaires et/ou de tests d'integration ?

En fait j'ai un peu un mix des deux dans mon projet. Mais changer la connectionstring c'est pour la partie test d'intégration.
Et la je n'ai pas encore compris comment on spécifie dans les tasks de la release comment définir les connexionstrings pour mes tests ...