What strategy would you use to manage the releasing of versioned software to Azure cloud services (web and worker roles)? We are not looking for continuous integration. We are using Visual Studio 2013 and Visual Studio Online (Cloud TFS).

At one point, we were releasing straight from Visual Studio using the Azure Cloud Project Publish tool. This is really bad practice in my opinion as you can never be sure what you are really releasing. Additionally, there is no automated control on the labeling or branching of code, or the running of unit tests and code analysis checks.

Next, we employed Release builds on Visual Studio Online. Before deployment, one would edit the appropriate Build Definition (whether it be for Test or Production by and filling in the code label (under the "Get Version" build property) that is to be released. This would then get the appropriate code (by the label specified), build it, and release it to whatever cloud service is specified in the targeted Cloud Project profile (this is using the AzureContinuousDeployment.11.xaml template).

There is still a degree of manual intervention involved. Also, the fact that a version of code is built every time before it is released is not ideal (as far as I understand it would be better if it was packaged once).

Microsoft Release Management tools look ideal for the job, but are not supported with Visual Studio Online.

Is there a better way of handling our releases?

/waves hand.. These are not the tools you seek. You are looking for continuous integration.

Although CI has the word continuous in there, it does not mean "all the time, every checkin". It can easily refer only to those bits you want to release - -and the way to tell the system which bits you want released is to merge them to a Releases branch.

If you do this, not only do you get all the joy of controlled CI, but you guarantee what you release is exactly what is controlled in your SCM - under the Releases branch, preferably tagged or otherwise noted as a particular release. That means you can also rollback to a previous release by simply reverting to a previous release in your SCM!

Of course you don't have to let it happen automatically, you can set it up to build 'continually' and then remove the check on the SCM to see if any changes have been committed. You can replace this with the manual build button.

• Marked as answer by techhub1337 Thursday, January 15, 2015 11:21 AM

/waves hand.. These are not the tools you seek. You are looking for continuous integration.

Although CI has the word continuous in there, it does not mean "all the time, every checkin". It can easily refer only to those bits you want to release - -and the way to tell the system which bits you want released is to merge them to a Releases branch.

If you do this, not only do you get all the joy of controlled CI, but you guarantee what you release is exactly what is controlled in your SCM - under the Releases branch, preferably tagged or otherwise noted as a particular release. That means you can also rollback to a previous release by simply reverting to a previous release in your SCM!

Of course you don't have to let it happen automatically, you can set it up to build 'continually' and then remove the check on the SCM to see if any changes have been committed. You can replace this with the manual build button.

• Marked as answer by techhub1337 Thursday, January 15, 2015 11:21 AM

I'd love to help, but this looks like an overall Azure question.  Is there something that's specific to Azure SQL Database that I can help with?

Thanks Guy