Cloud Zone is brought to you in partnership with:

Maarten Balliauw is a Technical Evangelist at JetBrains. His interests are all web: ASP.NET MVC, PHP and Windows Azure. He's a Microsoft Most Valuable Professional (MVP) for Windows Azure and an ASPInsider. He has published many articles in both PHP and .NET literature such as MSDN magazine and PHP architect. Maarten is a frequent speaker at various national and international events such as MIX (Las Vegas), TechDays, DPC, ... His blog can be found at http://blog.maartenballiauw.be. Maarten is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website. View Full User Profile

Running Unit Tests When Deploying to Windows Azure Web Sites

01.31.2013
| 1831 views |
  • submit to reddit

 

When deploying an application to Windows Azure Web Sites, a number of deployment steps are executed. For .NET projects, msbuild is triggered. For node.js applications, a list of dependencies is restored. For PHP applications, files are copied from source control to the actual web root which is served publicly. Wouldn’t it be cool if Windows Azure Web Sites refused to deploy fresh source code whenever unit tests fail? In this post, I’ll show you how.

Disclaimer:  I’m using PHP and PHPUnit here but the same approach can be used for node.js. .NET is a bit harder since most test runners out there are not supported by the Windows Azure Web Sites sandbox. I’m confident however that in the near future this issue will be resolved and the same technique can be used for .NET applications.

Our sample application

First of all, let’s create a simple application. Here’s a very simple one using the Silex framework which is similar to frameworks like Sinatra and Nancy.


  <?php
  require_once(__DIR__ . '/../vendor/autoload.php');
  
  $app = new \Silex\Application();
  
  $app->get('/', function (\Silex\Application $app)  {
      return 'Hello, world!';
  });
  
 $app->run();

Next, we can create some unit tests for this application. Since our app itself isn’t that massive to test, let’s create some dummy tests instead:

  <?php
  namespace Jb\Tests;
  
  class SampleTest
      extends \PHPUnit_Framework_TestCase {
  
      public function testFoo() {
          $this->assertTrue(true);
      }
 
     public function testBar() {
         $this->assertTrue(true);
     }
 
     public function testBar2() {
         $this->assertTrue(true);
     }
 }

As we can see from our IDE, the three unit tests run perfectly fine.

Running PHPUnit in PhpStorm

Now let’s see if we can hook them up to Windows Azure Web Sites…

Creating a Windows Azure Web Sites deployment script

Windows Azure Web Sites allows us to customize deployment. Using the azure-cli tools we can issue the following command:

view sourceprint?1.azure site deploymentscript

As you can see from the following screenshot, this command allows us to specify some additional options, such as specifying the project type (ASP.NET, PHP, node.js, …) or the script type (batch or bash).

image

Running this command does two things: it creates a .deployment file which tells Windows Azure Web Sites which command should be run during the deployment process and a deploy.cmd (or deploy.sh if you’ve opted for a bash script) which contains the entire deployment process. Let’s first look at the .deployment file:

 [config]
 command = bash deploy.sh

This is a very simple file which tells Windows Azure Web Sites to invoke the deploy.sh script using bash as the shell. The default deploy.sh will look like this:

  #!/bin/bash
  
  # ----------------------
  # KUDU Deployment Script
  # ----------------------
  
  # Helpers
  # -------
  
 exitWithMessageOnError () {
   if [ ! $? -eq 0 ]; then
     echo "An error has occured during web site deployment."
     echo $1
     exit 1
   fi
 }
 
 # Prerequisites
 # -------------


This script does two things: setup a bunch of environment variables so our script has all the paths to the source code repository, the target web site root and some well-known commands, Next, it runs the KuduSync executable, a helper which copies files from the source code repository to the web site root using an optimized algorithm which only copies files that have been modified. For .NET, there would be a third action which is done: running msbuild to compile sources into binaries.

Right before the part that reads # Deployment, we can add some additional steps for running unit tests. We can invoke the php.exe executable (located on the D:\ drive in Windows Azure Web Sites) and run phpunit.php passing in the path to the test configuration file:

##################################################################################################################################
  # Testing
  # -------
  
  echo Running PHPUnit tests.
  
  # 1. PHPUnit
  "D:\Program Files (x86)\PHP\v5.4\php.exe" -d auto_prepend_file="$DEPLOYMENT_SOURCE\\vendor\\autoload.php" "$DEPLOYMENT_SOURCE\\vendor\\phpunit\\phpunit\\phpunit.php" --configuration "$DEPLOYMENT_SOURCE\\app\\phpunit.xml"
  exitWithMessageOnError "PHPUnit tests failed"
 echo

On a side note, we can also run other commands like issuing a composer update, similar to NuGet package restore in the .NET world:

echo Download composer.
 curl -O https://getcomposer.org/composer.phar > /dev/null
 
 echo Run composer update.
 cd "$DEPLOYMENT_SOURCE"
 "D:\Program Files (x86)\PHP\v5.4\php.exe" composer.phar update --optimize-autoloader
 

Putting our deployment script to the test

All that’s left to do now is commit and push our changes to Windows Azure Web Sites. If everything goes right, the output for the git push command should contain details of running our unit tests:

image

Here’s what happens when a test fails:

image

And even better, the Windows Azure Web Sites portal shows us that the latest sources were commited to the git repository but not deployed because tests failed:

image

As you can see, using deployment scripts we can customize deployment on Windows Azure Web Sites to fit our needs. We can run unit tests, fetch source code from a different location and so on. Enjoy!

Published at DZone with permission of Maarten Balliauw, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)