Continuous Deployment (GitHub) with Azure Web Sites

Standard

Windows Azure websites supports Continuous Deployment. Continuous Deployment can be thought as an extension of continuous integration, where when ever users commit a changeset, build will be triggered. And in case of Continuous Deployment, the changes will be published to your live application directly from source control, when ever user commits a changeset. This is a fantastic automation feature that can be leveraged from a range of source control tools such as Visual Studio Online and others (GitHub, BitBucket, DropBox, CodePlex, or Mercurial) . Azure websites supports staged publishing (it is in Preview state) as well, so if you don’t want to publish your changes direcly to live, you can deploy it to staging and verify it. Once verification is completed, you can push the staging to live.

In this post I will be describing the deploying to direct live environment approach only. I am using GitHub as my source control. First you need to create Website. You can do it from Azure portal or from Visual Studio. Once you created website, go to the Dashboard and select the option “Set up deployment from source control”

Set up deployment from source control

Set up deployment from source control

Now select GitHub from the list.

GitHub from Source code repository list

GitHub from Source code repository list

Azure will popup GitHub authentication and authorization window, once you authorize, you need to select the source code repository.

Select GitHub repository

Select GitHub repository

Once you choose source code repository, if the repository contains source, it will be pushed to the live environment. To verify continues deployment, you can modify the source and publish the changes.

In this post I have enabled Continuous Deployment for a HTML5 single page application. Now I am integrating VisualStudio online Application Insights code to the HTML page.

Integrating application insight code to HTML Page

Integrating application insight code to HTML Page

Now commit the changes (I have added a description – “Application insights code added Application insights code added”) and publish the source code. You can verify the Deployments Tab in Azure portal and can see the changeset applied.

Deployments Tab in Azure portal

Deployments Tab in Azure portal

You can see the comment in the active deployment – “Application insights code added Application insights code added”

I will post about staging deployment later.

Happy Programming :)

How to use NuGet without adding packages to TFS

Standard

In the recent project I was using few nuget packages. And I was using TFS. Committing these packages into TFS was increasing the size of the repository. Later I found a solution using Enable NuGet Package Restore option. You can enable this option by right clicking on the solution file or from Project > Enable NuGet Package Restore option.

Enable NuGet Package Restore option

Enable NuGet Package Restore option

This will show up a confirmation message like this.

Enable NuGet Package Restore Confirmation

Enable NuGet Package Restore Confirmation

Once you accepts it, Visual Studio will add a .nuget folder to the solution, you need to check in the solution to TFS.

.NuGet folder in solution explorer

.NuGet folder in solution explorer

The nuget.config file contains following XML.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
</configuration>

The disableSourceControlIntegration setting instructs version control systems like TFS to not add the NuGet packages folder to the pending check-ins list.

Now you can delete the packages folder and try to build it again, Visual Studio will be downloading packages for you.

Build - Output Window

Build – Output Window

Happy Programming.

Unexpected error encountered opening Visual Studio project

Standard

Today while opening a win-form project, I got an exception message like this from Visual Studio.

Visual Studio - Un Expected Error

And then the Visual Studio project was not available in the solution. All the project said was “The project file cannot be loaded.”

This error is because the project was under Subversion version control, and I don’t have Subversion installed on my system. To resolve this error, open the project in notepad(if you have power tools installed, it will help to open project file as XML file).

Project File as XML

And remove the xml tags which is pointing to the source control. Now save and close the project file, and re open with Visual Studio, it will load without any problem.

Happy Programming.

Continuous integration using TFS 2012 express edition – Creating Build definition

Standard

This post is about creating build definition. Build definition play a key role in continuous integration. Each build definition contains instructions about which code projects to compile, what action should trigger a build, what builds should be retained, and where build output should be copied.

To create build definition, Select the Builds menu item from the Team Explorer window, it will be like the following image.

Team Explorer - Builds

Team Explorer – Builds

Click on new build definition link button, which will open a new Tab in VS 2012 Express, like this. A new build definition has five tab pages.

  • General – Like previous version of Visual Studio, it contains build definition name and description. Additional to that, it allows to control build queues, like Enabled, Paused, Disabled. The Paused option is a new feature, which allows to queue the build, but build will start only when administrator starts it.

    General Tab - Build definition

    General Tab – Build definition

  • Trigger – This page contains the various check in triggers, which is same as the previous version.
    Trigger Tab - Build definition

    Trigger Tab – Build definition

    Here is the various trigger modes available.

    • Manual – In this mode, checks won’t trigger a build, instead users need to queue new build after check in.
    • Continuous Integration – The build will trigger, when ever there is a check in. Suitable for Continuous Integration builds
    • Rolling Builds – As the name defines, this build will be always running. It will accumulate all the check-ins until the prior build finishes.
    • Gated Check in – In this mode before the check-in is committed, the build must succeed. So, instead of the check-in causing the build, the build is forced to happen first and then the check-in can finish. This is best suitable build mode for projects like Frameworks. In TFS 2012, there is Merge and build up to n submissions option is available, which helps to specify the maximum number of check-ins you want to build together in any given batch. In general, you don’t risk much disruption by using this option. Each check-in is individually committed or rejected.
    • Schedule – This option can be used for Regression / Nightly kind of builds. This will run on specified day on specified timings.

    We are selecting the second option, Continuous Integration.

  • Workspace – This tab is same as old versions, which helps to define the workspace for build.what part of the source control tree that should be downloaded as part of the build.
    Workspace Tab - Build definition

    Workspace Tab – Build definition

    Here I set the $/WebFramework as my workspace root. You always want to make your workspace as small as possible to speed up build time.

  • Build Defaults – In page, we can define the Build controller, and the Drop location(build output location).
    Build Defaults Tab - Build definition

    Build Defaults Tab – Build definition

    Note: It should be a UNC path, otherwise build may not work correctly. As I am doing a single machine setup, I shared a Folder, used that path as the UNC Path.

  • Process – This page contains information on exactly how and what the build will do.
    Process Tab - Build definition

    Process Tab – Build definition

    The build process templates will display which template is used for builds. The template is XAML file, but VS Express 2012 doesn’t support editing these files with the Designer. So for setting up the build definition, I just modified the Items to build. As I am building a class library, the configurations to build kept as AnyCPU|Release. And project to build, pointed to the solution of the Framework solution file. In the Basic category, there is an option to run Automated Tests as part of build activity, where we need to provide the pattern to identify test assemblies, it will be like assembly.Test.dll.

  • Retention Policy – In the page we can configure how many builds need to be retained.

    Retention Policy - Build definition

    Retention Policy – Build definition

We are done. Save the build build definition. Modify any code, check in the code, which will trigger a new build, and which will display a summary like this.

Build Summary

Build Summary

Happy Continuous integration :)