How to install an Azure App in test and production environments : Comment installer une application Azure dans les environnements de test et de production

 

English	Français
I was recently asked the question: how do I deploy in test and production? Here are a few explanations on that topic, as well as useful resources.	On m’a récemment posé la question suivante: comment déploie-t-on en test et en production? Voici quelques explications sur le sujet, ainsi que des ressources utiles.
First, let’s explain how this could look like, with or without having Azure (or any cloud) as a destination.	Tout d’abord, expliquons comment cela peut se présenter, avec ou sans Azure (ou tout autre nuage) comme destination

Developers write code and check it in the source control repository. A build process gets source code, compiles it, executes a bunch of automated tests, and generates a package that can be installed in different of environments. For the sake of simplicity, let’s suppose we have two environements: test and production.	Les développeurs écrivent du code et le mettent dans le gestionnaire de sources. Un processus de construction récupère le code source, le compile, exécute un certain nombre de tests automatisés, et génère un paquet qu ipeut être installé dans différents environnement. Pour rester simple, supposons ici qu’on n’a que deux environnements: test et production.
Once testers have validated the application in the test environment, the same package can be depoyed to production.	Une fois que les testeurs ont validé l’application en environnement de test, le même package peut être déployé en production.
So what is different with the cloud?	Qu’est-ce qui est différents avec l’informatique en nuage?
The main difference is that it is easy to have any environment like the production environment provisioned for some time, and you only pay for the time you use it. So you can have 5 different test environment for one week, and zero test environment the next week.	La principale différence est qu’il est facile d’obtenir n’importe quel environnement semblable à la production pour un certain temps, et l’on ne le paie que pendant le temps où on l’utilise. Ainsi, on peut avoir 5 environnement de test différents pendant une semaine, et aucun environnement de test la semaine qui suit.
But let’s stick to the scenario with a test environment and the production environment. What will make an environment THE production environment is the URL it is associated to: this is THE url you gave to the end users.	Mais restons-en au scénarioavec un environnement de test et un environnement de production. Ce qui va faire d’un environnement l’environnement de LA production est l’url à laquelle il est associé: c’est L’url que l’on a donée aux utilisateurs finaux.
Let’s suppose in our example that the production URL is www.contoso.com. It will correspond for instance, thru a CNAME entry in Contoso.com’s DNS to contoso-www.cloudapp.net. This contoso-www Azure hosted service would have been created from the Windows Azure Portal (or thru management API) like this:	Supposons dans notre exemple que l’URL de production est www.contoso.com. Cela correspondra par exemple, via une entrée de type CNAME dans le DNS de contoso.com à contoso-www.cloudapp.net. Ce service hébergé contoso-www.cloudapp.net peut avoir été créé depuis le portail de gestion Windows Azure (ou via les API de gestion) de la façon suivante:

similarily, a hosted service can be created for the test environment

de même, un service hébergé peut être créé pour l’environnement de test

this results in the following modification of the figure:

Cela nous fait préciser le schéma de la façon suivante:

For the production environment, downtime during upgrades should be minimal or null, and going backward in case of an error should be possible. For that, any Azure hosted service has a staging and a production slot. The production slot is the one having the main URL (like contoso-www-test.cloudapp.net or contoso-www.cloudapp.net) while the staging environment has a URL that is automatically generated (and which is hard to discover for someone not having access to the management API or the management portal).

Pour la production, le temps d’indisponibilité pendant la mise à jour doit être minimal, voire nul, et pouvoir revenir en arrière en cas de problème doit être possible. Pour cela, tout service hébergé Azure a un emplacement intermédiaire et un emplacement de production. L’emplacement de production est celui qui correspond à l’URL principale (comme contoso-www-test.cloudapp.net ou contoso-www.cloudapp.net) alors que l’emplacement intermédiaire a une URL qui est automatiquement générée (et qui est difficile à découvrir pour qui n’a pas accès aux API ou au portail de gestion).

I wrote an article about that feature and how the virtual IP address behaves a few weeks ago. The figure would now look like this:

J’ai écrit un article à propos de cette fonctionnalité et comment l'adresse IP virtuelle se comporte il y a quelques semaines. le schéma ressemble maintenant à cela:

What I’ve just been describing is only for compute part of Azure; the application may also use SQL Azure, Windows Azure storage, Windows Azure AppFabric Service Bus and so on. At each level of the application, it is necessary to have a different instance of the Azure assets. All those are cloud elements and are also easy to provision (ex: it takes seconds to create a SQL Azure database or even a SQL Azure server).	Ce que je viens de décrire concerne seulement la partie exécution dans des machines virtuelles (les rôles) d’Azure; l’application peut aussi utiliser SQL Azure, le stockage Windows Azure, le bus de sevice Windows Azure AppFabric etc. A chaque niveau de l’application, il est nécessaire d’avoir des instances différentes de ces éléments Azure. Tous sont des éléments en nuage et sont aussi faciles à créer (ex: cela prend quelques secondes de créer un base SQL Azure ou même un serveur SQL Azure).
An important decision to make is to define at which levels environments are separated. For instance, two SQL Azure databases can live in different Azure accounts, in different SQL Azure servers or just as different SQL Azure databases in the same SQL Azure server.	Une décision importante à prendre est de définir à quels niveaux les environnements sont séparés. Par exemple, deux bases SQL Azure peuvent se trouver dans des comptes Azure différents, dans des serveurs SQL Azure différents ou juste en tant que bases de données SQL Azure différentes dans un même serveur SQL Azure.
In the following example, the production and the test databases live in different servers inside the same account:	Dans l’exemple suivant, les bases de production et de test se trouvent dans des serveurs différents du même compte:

 

It is also a good practice to automate deployments so that deployment to production is less human error prone. Generally speaking, all actions that can be done manually thru the Azure Management Portal can also be automated thru the Azure Service management API. The API were used to create Powerscript cmdlets, and the second version of these as just been released a few days ago. Here is the URL where you can find the documentation and download them:

C’est aussi une bonne pratique d’automatiser les déploiements de façon à ce que le déploiement en production ne soit pas sujet à erreur humaine. De façon générale, toutes les actions que l’on peut faire à travers le portail de gestion Azure peuvent aussi être automatisées via les API de gestion Azure. Ces API ont été utilisées pour créer des cmdlets Powerscript, et la deuxième version vient de sortir. Voici l’URL à laquelle on trouvera de la documentation et où l’on peut les télécharger:

https://wappowershell.codeplex.com/documentation

It is also possible to integrate the automated deployment into the build process. Tom Hollander as a great blog post on this. The post also provides some sample script based on the cmdlets.	Il est également possible d’intégrer le déploiement automatisé dans le processus de construction. Tom Hollander a un très bon billet sur le sujet. Le billet fournit également un exemple de script à base de cmdlets.
As automated deployment is integrated into the build process, it is even possible to imagine that it can create an new test environment at the end of each branch in the source control…	Une fois le déploiement automatisé intégré dans le processus de construction, il est même possible d’envisager qu’il crée un nouvel environnement de test à la fin de chaque branche du gestionnaire de sources…
For more in-depth guidance on this, please read the following from the Microsoft Patterns & Practices group:	Pour plus de recommandations dans le détail sur le sujet, on pourra se référer à l’article suivant du groupe Patterns & Practices de Microsoft:

Application Life Cycle Management for Windows Azure Applications

 

Benjamin