Chapter 3

Managing Deployments via Source Control

IN THIS CHAPTER:

  • Associating a version control system with your Azure account
  • Using source control repositories to publish Azure Web Sites
  • Working with different versions of a previously deployed code base

WROX.COM CODE DOWNLOADS FOR THIS CHAPTER

Please note that all the code examples in this chapter are available as a part of this chapter’s code download on the book’s website at www.wrox.com on the Download Code tab. You’ll be publishing all the related code from the following project in the download:

SimpleSite — This is a Visual Studio 2012 solution that you will use as a publishing exercise throughout this chapter.

It is often said that the only good code is shipped code. Until code is shipped, users gain no benefit from our efforts. And on too many occasions, the time between development and deployment into production can be measured in weeks and months. So how great would it be to have code shipped as soon as it’s checked in? This is an idea that has been gaining support for quite a while. Support not just in terms of people approving of the idea, but also in the number and quality of tools used to actually deliver on it. Developers can add Windows Azure Web Sites to the list of tools that help achieve this laudable goal.

Developers don’t go out of their way to make their deployment process intentionally more complex. They don’t add extra tools to their toolkit for the heck of it. They have no desire to make it difficult for the team to work together. The process of developing code, integrating new functions into the application, and performing tests is already challenging to do. There is no benefit to making the points of interaction among the team members worse.

And yes, the build or deployment process is often a point of tension on many teams. Perhaps the build is fragile. One small piece out of place and tests start to fail. Or maybe the build is inconsistent, showing failure one moment and success immediately afterwards. Any situation like this is one that development teams want to avoid.

Typically, at the onset of a project, someone will lead the effort to put the build together. They wire up the compilation of the separate projects and create scripts for the deployment and testing steps. This can be intimidating. And to make it worse, the most typical pattern has the build changing on a regular basis over the development period as more and more functionality is added.

Many good patterns exist for creating a seamless build and deployment experience. If your build and deployment systems are not causing pain in your daily work, there may be very little business value in changing it. This chapter should not be viewed as a demand to rewrite your deployment process. If, however, the only continuity in your build process is “stress,” then it might be time to consider an alternative approach.

As your development toolkit has grown and matured, so has the general landscape for the build process. Continuous Integration servers are equipped with web-based front ends that are capable of monitoring changes to source control, checking out code, executing build scripts, performing automatic acceptance tests, staging deployments to multiple servers, as well as myriad other tasks. These systems will not be perfect for every team, every scenario, or perhaps even for your project requirements, but they are good to be aware of so that when you are ready, you’re equipped with the pieces you need to deliver a timely and comprehensive solution.

Now, the fact that Windows Azure can integrate easily and rather seamlessly into your continuous deployment process won’t solve all your problems. But it does mean that Azure is a solid choice for a deployment target. And as an added benefit, configuring Azure and your build environment to accomplish this is not as intimidating as you might first think. After looking at the basics of working with source control systems, this chapter discusses the components of this process that make it easier to automate the juicy bits.

UNDERSTANDING PREREQUISITES

For most of the exercises that follow, you will be required to provide credentials in the Windows Azure portal for external source control systems. Each of these systems requires a varying degree of configuration and may require tool installation or shell extensions in order for you to work with them on your machine.

The focus of this chapter is to help you understand how source control tools (specifically the deployment components of those tools) allow for integration with Windows Azure Web Sites. That means that this chapter does not provide a comprehensive guide to installing, configuring, or managing your choice of source control. That is well beyond the scope of this chapter and this book. The assumption is that you have already selected a source control tool; this chapter covers four popular tool choices and how they work with WAWS.

You should have a good understanding of your tools of choice, the ability to check in code changes, and familiarity with creating branches and merging code as required. Using a variety of tools, I will demonstrate how diverse this process can be, but the examples will not serve as a tutorial for managing your source tree.

Finally, you should be comfortable with creating new Azure Web Sites and moving around the Windows Azure portal — specifically, with using the command bar and navigating to the dashboard of the website you’re working with.

PUBLISHING FROM SOURCE CONTROL

In Chapter 2 you had a quick look at publishing from Dropbox. It is straightforward enough, and while it maintains history on files and integrates nicely into modern operating systems, it is missing some critical aspects of source control when used on its own. Although it is possible to create composite solutions — Git or Mercurial over Dropbox, for example — they rarely satisfy more than single-user requirements, and even then ideally only for backup and redundancy. Therefore, as simple as it is to set up Dropbox with Windows Azure Web Sites, it’s probably not a real-world solution for your team. The following sections describe how to configure WAWS publishing from GitHub, CodePlex, Bitbucket, and Team Foundation Service.

Publishing from GitHub

GitHub is one of the fastest-growing hosts of open-source software projects, enabling private or public collaboration within organizations, between individuals and as a community. Though there is a for-fee model, you can make as many public repositories as you like, fork code from existing efforts, and contribute to projects created by others.

From Windows Azure Web Sites you are able to connect your site to any GitHub project associated with your account. This includes any public or private repositories you’ve created, as well as projects that you’ve forked from other sources. Better still, you can select the branch to be associated with your website, which allows for great flexibility in running multiple environments and deployment versions. Using a custom deployment engine, Windows Azure Web Sites will download code after a check-in, build your solution, and deploy your updated site automatically.

To get started, you’ll need to set up a local repository and put some code in it. This section provides instructions assuming you’ll be using GitHub for Windows as your client software. GitHub for Windows is an excellent GitHub client with a very streamlined UI that should feel right at home in your Windows environment. If you prefer to use another client, you should be able to tailor the process accordingly:

1. From the home screen in GitHub for Windows, create a new repository using the add button located at the top center of the screen. When you are done, open the repository in GitHub for Windows.
2. From File Explorer, copy the files for the Simple Site into your repository’s local directory. The site solution is located in the Basic Site Publishing Files folder of the code download.
3. Return to the GitHub client to commit and publish your changes. You’ll need to write a short note to describe your commit as required by the software — “Initial Commit” is fine — and then click Commit, followed by the sync button at the top of the client.

At this point your source code has a home on GitHub. All you need to do now is teach Windows Azure Web Sites how to deal with your repository:

1. Create a new website using the Quick Create template. You can create a new website from anywhere in the portal by clicking the New link in the command bar.
2. From the website dashboard, click the link to “Set up deployment from source control.” This is located under the Quick Glance area of the dashboard.
3. Select GitHub from the list of providers and click the next arrow.
4. Authorize the application. GitHub prompts you to let you know that Azure will have permission to read your public and private repositories. Review the details and grant Azure access by clicking the Authorize app button.
5. Select the repository from the list and specify your branch. The dropdown will contain a list of Git repositories that are available to you, grouped by organization. The master branch is set as the default for you.
6. Click the checkmark to complete the association. You’ll see a message similar to the one shown in Figure 3-1, letting you know that the link is being established.

FIGURE 3-1

image

You’ll need to let Azure plug away as it creates the link (which is actually a type of service hook called a WebHook), clones the repository, compiles your solution, and deploys your site. The process is soon completed, with the current version of your source code showing as the active deployment. You can click the Browse button in the command bar to see the site.

NOTE
The WebHook won’t always clone your repository, though it will be required the first time you associate your site with source control. After the initial clone, Azure just pulls against the repository to update the relevant files for any subsequent deployment.

Publishing from CodePlex

CodePlex is a hosting site provided free of charge from Microsoft for open-source projects. It allows easy collaboration and multiple options for source control, so publishing from CodePlex is a bit of a meta-operation, as you can choose your client and source control platform from an array of options.

In order to enable support for your website to build and deploy from CodePlex, you’ll need to have your project in the following state:

  • Your project must use Git or Mercurial as the source control provider.
  • Your project must have source checked in.
  • You must have already published your project.

You can use the following steps to start from a newly created CodePlex project or adapt them as required to fit your project’s status:

NOTE
Git Bash, referred to in the upcoming steps, is a command-line tool that can be used to manipulate Git repositories and source code. It is installed at the same time as Git. Git Bash is not the only mechanism available to clone a repository from CodePlex. Others, such as Source Tree, are freely available for download from the Internet. It is, however, included with Git and so it doesn’t require any additional setup on your computer. That is its reason for being used in these steps.
1. Create a new project on CodePlex. You’ll need to be signed in, and your project needs to be uniquely named.
2. Navigate to the Source Code tab on your project. There will be no changesets here, as the project is still fresh.
3. Capture the clone URL for your project to the clipboard. You can reveal the URL by clicking the Clone submenu.
4. Using Git Bash, clone the repository from CodePlex. Use the following commands, substituting your proper project name and local working directory. Leave Git Bash open when you are done. 
   git clone https://git01.codeplex.com/YourProjectName YourLocalDirectory
   cd YourLocalDirectory
5. Use File Explorer to copy the Simple Site into the Git repository you just created. The site solution is located in the Basic Site Publishing Files folder of the code download.
6. Commit your changes and push to CodePlex from Git Bash. You can use the following commands to add the files to the repository, create your initial commit, and complete the push: 
 git add .
 git commit -m 'initial commit'
 git push -u origin master
NOTE
If you have not previously saved your credentials for CodePlex, Git will prompt you for your username and password for operations such as clone and push. You will need to use the same username and password that you use to log into the CodePlex website.

You’ll see all the files scroll by as the operation completes, and you will be able to browse the code in CodePlex immediately.

As shown in Figure 3-2, publishing your project also requires a number of other elements. In addition to pushing your first set of code, you’ll need to edit your home page, select one of the open-source licensing models available on the site, and finalize your project summary.

FIGURE 3-2

image

Complete each of those requirements, then follow these steps in your Azure portal to connect to CodePlex for automatic deployments:

1. Create a new website using the Quick Create template. You can create a new website from anywhere in the portal by clicking the New link in the command bar.
2. From the website dashboard, click the link to “Set up deployment from source control.” This is located under the Quick Glance area of the dashboard.
3. Select CodePlex from the list and click the next arrow.
4. Authorize the application. Review the details of the permissions you’re granting Azure and click the Authorize button.
5. Select the repository from the list. The dropdown will contain all published sites that are bound to Git or Mercurial source control.
6. Click the checkmark to complete the association.

It doesn’t take long for things to happen from here. Azure will scoop up the latest check-in, build your solution, and then copy the output from the build to the active deployment for your site. Click the Browse link in the command bar to launch the site.

Publishing from Bitbucket

Originally tied to Mercurial, Bitbucket added support to the popular Git repository system in 2011, offering an array of integration features — with everything from other source control systems to social networks. The system enables you to maintain private and public repositories, fork and clone other people’s projects, perform code reviews, track issues, and more.

Because of the support for Git, you can leverage the same source code directory that you used for publishing to CodePlex:

1. Create a new repository from your Bitbucket account and capture the Git endpoint to the clipboard. You can see the URL for your repository on the repository’s Overview page.
2. From Git Bash, switch to the directory you created in the previous exercise. Use the following command, with the correct path: 
   cd YourLocalDirectory
3. Add the remote repository for Bitbucket and push your commits. Use the following commands, replacing the URL with the one you copied to the clipboard in step 1: 
 git remote add bitbucket https://[email protected]/username/YourSiteName.git
 git push -u bitbucket --all

Your final session from Git Bash will look something like Figure 3-3, with the obvious bits reflecting your path, username, and project name.

FIGURE 3-3

image

Now that your code has a comfy new place to hang out on Bitbucket, the final step is to get Windows Azure Web Sites chatting with the source repository. The steps are very similar to the other Git-based control systems:

1. Log in to the Azure Portal and create a new website using the Quick Create template. You can create a new website from anywhere in the portal by clicking the New link in the command bar.
2. From the website dashboard, click the link to “Set up deployment from source control.” This is located under the Quick Glance area of the dashboard.
3. Select Bitbucket from the list and click the next arrow. You will be prompted to enter your credentials to log into your Bitbucket account.
4. Authorize the application. Review the details of the permissions you’re granting Azure — read and write permissions on both private and public repositories — and click the “Grant access” button.
5. Select the repository from the dropdown list and then select a branch. You can choose any repository that your account has permission to view, and any branch in that repository.
6. Click the checkmark to complete the association.
NOTE
The Git-based repositories are configured with a POST URL when you create the association with your Windows Azure Web Site. The Git control system you have linked with will POST to that address when a new commit is made, thus enabling continuous deployment. If you want to disable the continuous feed, you need to do this in the respective system. For example, in Bitbucket, you would go to the repository’s settings, select Services, and change or remove the POST URL present among your services integration details.

Publishing from Team Foundation Service

The flagship of collaboration for teams that develop on the Microsoft stack, Team Foundation Server has really broadened its horizons. Once a tool often feared and misunderstood, TFS relied heavily on a thorough understanding of the “Visual Studio way” and a persistent connection to a central server. Today, Team Foundation Server has re-manifested itself in other incarnations that support distributed source control, and it can be served up in web-sized doses that please developers of all walks.

The incarnation you’ll be working from here is Team Foundation Service, accessible at tfs.visualstudio.com, and it works a little differently than the other source control services you have examined in this chapter. Rather than pull in source code and build the solution, TFS publishes the build to the connected Windows Azure Web Site when a check-in builds successfully. In addition, you can integrate a whole host of other options into the build process as well, giving you quite a bit of control and flexibility over how your deployments are built and managed.

Here are the steps you must perform to wire up your solution to TFS and ultimately enable publishing from Team Foundation Service:

1. Log into TFS and create a new Team Project using the default settings. For process template choose “Microsoft Visual Studio Scrum” and select “Team Foundation Version Control” for version control.
2. Open the Simple Site solution in Visual Studio 2012. This solution is located in the Basic Site Publishing Files folder in the code download.
3. Connect to the Team Project you created in TFS. Select Team image Connect to Team Foundation Server from the Visual Studio menu. Follow any authentication prompts and configure your connection to your TFS server, if required. Select your Team Project and click Connect.
4. Add the solution to the Team Project. From Solution Explorer, right-click on your solution and select Add Solution to Source Control, then click OK.
5. Check your solution in. From Solution Explorer, right-click on your solution and select Check In..., and then click the Check In button on the Pending Changes panel.

Your solution is now wired to automatically build whenever you check in files, as a default Continuous Deployment build configuration will be added to your Team Project.

The next step is to associate your Windows Azure Web Site to this build server through the Azure portal:

1. Create a new website using the Quick Create template. You can create a new website from anywhere in the portal by clicking the New link in the command bar.
2. From the website dashboard, click the link to “Set up deployment from source control.” This is located under the Quick Glance area of the dashboard.
3. Enter your Team Foundation Service URL, which you can find on the Account Home page of TFS under the Getting Started title. You will be prompted to allow the link from TFS to Azure, which you should accept.
4. Select the project you want to associate to the website. After authenticating and completing the link, the Azure portal loads the list of projects associated with your URL and presents them in a dropdown. Choose your project and click the checkmark to confirm your selections.

You’ll have to wait a moment or two while Azure completes the marriage between your website and the TFS project, but you should see a confirmation at the end of the process as shown in Figure 3-4.

FIGURE 3-4

image

The next step is to trigger a build, which in turn pushes deployment out to your site. Almost there!

1. In Visual Studio, open Index.cshtml. It is located under the ViewsHome folder of the project.
2. Change the page’s <H2> tag to the following: 
   <h2>Phone Book</h2>
3. Check in your changes. You can right-click on the Index.cshtml file in Solution Explorer and select “Check in,” or navigate to your Team Explorer home page and select the Pending Changes link to do this.

This check-in activates the continuous integration trigger on your build configuration and will queue a build in TFS. When the build completes successfully, you’ll see the deployment process kick off from the Deployments tab of your website in the Azure portal, shown in Figure 3-5. At this point, it is important to note that step 3 is all you need to do going forward to update your website.

FIGURE 3-5

image

When the deployment is completed, Azure switches over to the new code base and your site is immediately live. You can view the results of your handiwork by clicking the Browse button in the command bar.

MANAGING PREVIOUSLY DEPLOYED RELEASES

There’s nothing worse than pushing a chunk of code out that introduces new problems, especially when you were trying to fix something in the first place! (Of course, this never happens to you because you all write tests, right?) Over the years you’ve likely come up with processes to make backups of your websites, or you check installers into your versioning control system to ensure that you could easily roll back if a deployment goes sideways on you. These were previously legitimate processes, but in today’s world of continuous integration and continuous deployment these manual methods of versioning tend to be difficult to use and require constant effort to maintain.

Or consider the situation in which you haven’t yet managed to work your project into SAAS nirvana, and you are managing several sites for multiple clients that are potentially running on different versions of your code base. You’re notified of a problem and you need to write unit or acceptance tests to identify which versions are affected, but your test and staging environments are matched to the latest version of the code base. How will you test each of the versions?

The concept of managed deployments makes this task trivial, as all previously deployed versions of your site remain persistent in your site’s dashboard. Better still, the deployments are available through the command-line interface, so they’re also scriptable, perfect for our world of continuous integration and deployment. You’ll get a chance to see this in action in Chapter 4, “Managing Windows Azure Web Sites from the Console.”

NOTE
Binding your website to a source control provider is not a permanent operation, and you can disconnect from source control rather easily from the Windows Azure portal. Keep in mind, however, that the list of previous deployments will be discarded when you complete the disconnection. This is one of the caveats you’ll face if you choose to switch your back-end link to source control.

The continuous deployment approach through source control systems is a fairly pleasant experience in its own right. Each deployment created from your check-in is persisted in the portal for each of your websites in Azure. You can access the complete list, a sample of which is shown in Figure 3-6, by navigating to the Deployments tab on any site configured for source control integration.

FIGURE 3-6

image

Let’s have a closer look at the information available for each deployment. Hover over any deployment to see an arrow in the top right corner that, when clicked, reveals details for the selected deployment, such as the active deployment shown in Figure 3-7.

FIGURE 3-7

image

Any previous deployment you’ve created can easily be redeployed from this list. Simply click on the deployment you would like to re-instate, then choose the Redeploy command from the command bar. You will be prompted for confirmation, but then the operation only takes seconds and your site will be running on an older version of your code base.

SUMMARY

Your familiarity with various source control systems puts you in an enviable position in the marketplace, and the ability to apply your knowledge to the cloud is an additional benefit. Using your skills with different versioning platforms, you have seen how simple it can be to tie a website hosted in Windows Azure back to a source control system. The process is further enhanced through automated builds and deployments following a successful check in through the supported providers.

Building on what you’ve learned about creating and managing sites in the previous chapters, you can now review previous deployments of your project and move between versions through the Windows Azure portal via your website’s dashboard. With a handle on these soft skills, you’ll next learn to manipulate Windows Azure Web Sites through the command-line interface (CLI).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset