In the beginning of the year Windows Azure Web Sites team has released a preview of the Staged Publishing functionality. The Staged Publishing allows you to create a staging site slot where you can publish a new version of the website and then test it before swapping to the production environment. This feature together with Continuous Deployment via GitHub, BitBucket or DropBox enables some very powerful deployment scenarios.
However the preview release did not provide the optimal experience for enabling Continuous Deployment (CD) for staging site. User had to configure a non-trivial workaround as described in blog post by Rick Rainey. Recently the Azure Web Sites team has released an update that fixes that problem and makes the setup of the CD with staged publishing very simple. This blog post describes how to enable CD from git repository located on BitBucket.
First, in order to use staged publishing you need to scale your web site to Standard mode:
After that you will be able to enable staged publishing:
When staged publishing is enabled you will see the staging site slot in portal.
Select it and then click on “Set up deployment from source control”:
In my case I created a repository on BitBucket where I have one simple php page just for demo purposes:
The repository gets synchronized with the staging site slot and then when I browse to it I get the result of executing the PHP script that was checked in to my repository.
The script detects whether it runs in production or staging slot by checking the Host header of the request:
<html>
<head>
<title>My first PHP page</title>
</head>
<body>
<?php
echo "<h1>Hello World! This is a new version!</h1>";
$host = $_SERVER['HTTP_HOST'];
$is_production = TRUE;
if (strpos($host, 'staging') !== FALSE)
{
$is_production = FALSE;
}
if ($is_production === TRUE)
{
echo "<h2>This code is running in production.</h2>";
}
else
{
echo "<h2>This code is running in staging.</h2>";
}
?>
</body>
</html>Now that I have tested the script in staging environment I can swap it to production environment.
After that when I browse to the production site I get the expected result:
Now let’s assume that I want to deploy a new version of my script. I make a change in the script, check it in and push it to the BitBucket repository. After that I go back to the deployment history of my staging site and do a sync operation. That pulls my recent changes into the staging slot:
Now I can test how it works by browsing to the staging site:
Note that the production site at ruslanycd.azurewebsites.net is not affected while I am testing and debugging my staging site. Once I am done with verification I do the swap operation again and the latest change is now live in the production site:
Hi
Thanks for the tutorial. What happens when you want to do the same thing with a WordPress site. It needs to change database credentials in wp-config.php file. How is that handled throughout the process?