On this blog we’ve only really looked at the leap of faith, the moment of truth: deployment itself, and some of the many ways to manage it. Of course, there’s a lot more to deployment than just pushing the button. Part of the magic of tools like Deployment Manager is that they do a huge amount of work both behind the scenes to to make it feel like that’s all there is to it, but in reality there’s a significant amount of preparation and fore-knowledge required, and a lot of literature available around the subject of ASP.NET MVC deployment in particular.
As many of you will be aware, if you’re getting into something new, you typically have to deal with known unknowns, and unknown unknowns. If you’re still getting to grips with deployment, then the sheer number of options, not to mention operational complexities and potential pitfalls, can seem overwhelming. If you want to scale up to continuous deployment, which is fast becoming vogue (if not accepted wisdom), add a few more challenges to the pile. Thankfully, a large chunk of this falls into the “known unknown” category, so you can anticipate it:
Good news! There is an ever-increasing library and information available to help you get to grips with the science and art of deployment – a quick Google is all you need.
Bad news! That number of resources really IS ever-increasing, so finding just the information you need is only going to get tricker.
Good news! There is at least one community-driven guide full of recommended reading on the subject matter, and curated by members of the community. While the guides is aimed at understanding ASP.NET MVC applications, how to deploy those applications is an essential part of that understanding.
Regardless of which environment you’re working with, continuous reading is absolutely essential. The rate of change in the development landscape is only accelerating, and the only way you’re going to keep your skills sharp is to at least have an idea of what your options are, and where to look for the stuff you know you don’t know. And that’s true whether you’re working with ASP.NET MVC or not – probably more so if not.
Of course, none of this necessarily helps you with your unknown unknowns. For that, the only remedy is experience – you’ve got to pick up a demo project and pull it apart to see what makes it tick. Or put something together to see where you get stuck. Or better yet, both.
ASP.NET MVC Deployment – Where to start?
At the beginning – the best way to start is by reading. And if you don’t know what you should be reading, then that’s where having the terrain mapped out by community experts comes in handy. If you’d like to start getting to grips with the scope of deployment, or would like to contribute to the community guide (and we’d love to have you involved), head over to WebDev.Simple-Talk.com and take a look.
It’s still a work in progress, so we’d love to get your feedback too – any suggestions or questions are welcome!
.NET, Development, Software Delivery
Today we released a brand new Visual Studio extension which allows you to create and publish ASP.NET website packages directly from VS without having to set up a continuous integration environment or use the command line! I’m going to give you a quick overview of how the new extension works, and most importantly why you would want to use it.
What does the Deployment Manager Visual Studio Extension do?
This one is really simple: the extension turns your ASP.NET website project into a package and then publishes this to your Deployment Manager package feed. You are then able to select the package from your package feed and create a release.
How do I get it?
You can download it from the VS Gallery website, or from within Visual Studio select “Extensions and Updates…” from the tools menu and search for Deployment Manager. You’ll have to restart VS before you can use the extension.
How do I use it?
I’m assuming you have already installed and set up Deployment Manager. If you haven’t just follow these instructions.
Once you’ve installed the extension, all you need to do to publish a package for deployment is right click on your project and select “Publish for deployment…”.
This will then launch the Deployment Manager Application Publisher. Simply fill in the URL for your Deployment Manager server (this is also the URL you use to view the web interface, for example http://server-name:8080). You will also need to enter the API Key for your user account.
Once you’ve filled in these details, click “Next >” where you can choose a package name and version. You can also decide which feed to publish your package to. The easiest option is just to pick the default “Deployment Manager package feed”
When you’re happy with everything, click Publish and your package will be created and published to your chosen package feed. The final step is to head over to the Deployment Manager web interface where you can deploy your package. You’ll find more information about how to configure deployments in our documentation.
Why would I want to use it?
Before we released this extension, the only way to create a package was to use a command line tool, which you’d typically do as part of your continuous integration process.
We heard from users that they wanted to evaluate Deployment Manager more easily, without the need to set up a continuous integration process. That’s where this extension really shines. It allows you to easily create packages so that you can see Deployment Manager in action performing deployments.
Then, in your own time, you can switch from using the extension to continuous integration later, and get all the advantages of continuous integration, for example knowing for certain that what went into the package is the latest version of the website that’s in source control.
.NET, Automated Deployment, New version, Red Gate Deployment Manager, Software Delivery
The blog has been a bit quiet recently. There is a good reason for this though; we’ve been feverishly working on a number of new Deployment Manager features including user permissions and package publishing tools. I’m going to quickly run through some of the new functionality that’s coming to Deployment Manager over the next month.
Publish packages directly from Visual Studio and SQL Server Management Studio
The new add-ins have now shipped and you can download them here:
- Visual Studio Extension - http://rd.gt/10p4l12
- Server Management Studio Add-in - http://rd.gt/10p4odi
Last month we released a beta of our SQL Server Management Studio add-in which allows you to create and publish database packages to Deployment Manager right from within your development environment. If you haven’t already experienced how easy it is to create database packages, try it now! But what about ASP.NET packages? Well, in the next few days we will be releasing our brand new extension for Visual Studio. Like its Management Studio counterpart, the VS extension will make it ingeniously simple to create and publish packages to Deployment Manager.
Using these add-ins will allow you to use or evaluate Deployment Manager without having to spend hours setting up a continuous integration environment and package feed. In fact it’s so much faster to set up Deployment Manager and publish packages, Emma our tester can now do it in under 3 minutes!
User permissions
Now this is the one we know you’ve been waiting for! Next month we’ll be bringing advanced user permissions which will give you granular control over who can deploy to a particular environment or project. We’ll post more about this in the coming weeks, but for now here’s a screenshot to whet your appetite.
Some code changes are bad. That badness might be encapsulated as some flawed logic, misunderstood syntax, unexpected dependency or unfortunate typo that leads to something happening that wasn’t meant to happen.
Although responsible software development teams take considerable care to avoid bad code changes and spend significant time trying to identify them before they are released into the wild, the occasional bad code change is unavoidable. When a bad code change is included in the collection of changes that are packaged into a product release, then there is a very real risk that bad things are going to happen to the users of that product.
In my previous post I explained how the Deployment Manager Team were able to quickly respond when a significant bug was found in our product because we release frequently. In this post, I want to reveal my two favorite reasons why frequent releases help in times of trouble, and I want to do that using the power of squirrels…
As we all know, squirrels are small rodents who eke out an existence operating on that fine line between slightly-sinister verminous pest and sweet, energetic furry friend. Whatever the view you take of these creatures, it’s hard not to admire their planning process when, during the plentiful autumnal months, they diligently prepare for the tougher times of winter.
Some types of squirrel, like the Red Squirrel, spend autumn collecting nuts in secret stashes. Others, like the Grey Squirrel, bury nuts in the ground in a multitude of locations. In either case, squirrels have good reason to store food for later in the year rather than eating it all right now; because their stockpile is going to be much more valuable to them in the coming, colder months.
However, what happens if Kevin the Red Squirrel happens to come across a hand grenade, mistaking it for a large and somewhat heavy nut? Kevin, who’s pretty bright for a squirrel, but whose knowledge of short-range explosive devices is somewhat limited, diligently drags his impressive find away, to deposit it in his family’s nut pile. He admires his towering hoard for a moment and then hurries off to gather more tasty stock.
The addition of Kevin’s hand grenade to the stockpile was definitely a bad change. It was a bad change that is unlikely to be discovered until the stash is needed most. Worse still, that change may well destroy the entire nut collection, wasting all the valuable food that had been collected over the past few months. Kevin is not going to be a popular squirrel.
Bad code changes are like hand grenades. From a distance they look like good code changes and are very difficult to pick out from a long list of changes – just like a grenade in a pile of nuts (hey, work with me here). So, when packaging-up those changes into a product release, it’s possible you won’t spot them. Hopefully, no user will ever ‘pull the pin’ on that grenade once it has been shipped, by specifying the exact combination of variable values and convoluted workflow required to realize the problem. Hopefully.
To protect ourselves and our products against the effects of these hand grenades we should reduce the number of changes we put into releases. This makes it easier for us to spot bad changes during release testing. It also means that if a problem is found, the development team are more likely to be able to identify the offending code quickly, because they can narrow down their search to the small delta since the last release. As the release is likely to contain work that has only just been completed, the developers can remember why they wrote the code the way they did, and stand a good chance of being able to tweak it to make things right, without any undesired side-effects.
This is one of my favorite reasons why frequent releases stop you from blowing your product up; a single release has a relatively low number of changes in it. As completed work is being packaged-up and released very regularly, there is no opportunity for a large delta to build up since your last release. This is advantageous because your development team can find the cause of a bug in a small list of changes much more quickly than they can in a long list of changes. If Kevin the Red Squirrel’s stockpile of nuts was smaller, he may well have decided that the large metal nut with the odd looking ring-pull really did warrant further investigation.
When we shipped a bug in a recent version of Deployment Manager we were able to make the decision to recall the release and fix the problem very quickly. This was because we were only talking about removing 2 weeks’ worth of features from the public domain, not 6 months’ worth. All our nuts were not in one big stash. We would have had to think long and hard about the decision if rescinding the release meant that long-promised features, months in development and released to great fanfare, had to be removed alongside the more minor feature that had the bug in it. We were able to remain calm about the decision, rather than pressurized under the weight of the value in the release.
This leads me to another of my favorite reasons why frequent releases are a good idea; the intrinsic value of a single release is relatively low. This means it’s less of a setback if the release goes up in smoke. If the loss of a release is going to be less of a setback, it’s easier to dispassionately make a decision about removing the release from the public domain. If Kevin’s nut stockpile was small, the fact that he had blown it into tiny pieces would not have condemned have him to a lean winter (Squirrel-fans, let’s agree that in our fable Kevin manages to escape the blast and survives).
We can sometimes convince ourselves that by stockpiling changes, the value of that completed work will somehow have increased in future months. Meaning when we finally release all that stored-up awesome stuff, we believe we’ll make a bigger splash in the marketplace or simply astonish our users with a ‘big bang’, revolutionary release. The problem is; that ‘big bang’ release description might be all too literal if we ship a ‘hand grenade’ change.
Automated Deployment, Development, Red Gate Deployment Manager, Software Delivery
Last month we shipped a version of Deployment Manager with a fairly unpleasant bug. My confession is, at some point in the future, we’ll do this again.
Let me explain
We’ve challenged ourselves on the Deployment Manager Team to release valuable updates to the product every two weeks. It’s possible that you may think that this (relatively) frequent release cadence could be the root cause of a bug sneaking into our product.
Could it be that this goal puts excessive time pressure on the team, forcing us to rush through our testing processes and improperly validate a release before it has to go out of the door? Would a three-monthly release cycle have meant that this bug was spotted?
Well, I really don’t think so. In fact, I think our release frequency means that we are more likely to spot bugs and better able to recover from them quickly.
Bugs are an inevitable consequence of building complex software in a finite amount of time, using humans. As much as we try to avoid bugs, occasionally they will sneak in, regardless of release cadence. If we accept this, then the only responsible thing to do is to optimise our system and processes so that we can recover from those bugs as quickly as possible.
So, let me tell you what happened when we released Deployment Manager v1.1.0.31.
Cue the flashback…
Our two-week sprint had gone well. The team had been working on improving two areas of Deployment Manager’s installation and evaluation process. Firstly, we’d streamlined the Deployment Agent installation process, vastly reducing the number of mouse clicks it takes to get an agent up-
and-running. Secondly, we had added an integrated package repository to Deployment Manager. This meant that users did not have to find and install a 3rd party NuGet repository prior to being able to use our product. The features had been swarmed-over by the whole team and were now complete; developed and validated by automated and manual tests. We were excited at the prospect of getting the features into users’ hands as quickly as possible.
At our morning stand-up meeting the team discussed whether we were happy to release the product. Our Testers had already reviewed the last automated test run and checked our automatically updated shared environment. We were content everything was green, so the conclusion was an emphatic “SHIP IT!”
Good to go
The awesome Red Gate DevOps team use Deployment Manager to deploy many of our internal systems. So, they are always the first people we update to new Deployment Manager releases. We update them using the same notification and delivery system we have built into Deployment Manager (we call that mechanism Check For Updates). We updated their Deployment Manager installation to our shiny new version 1.1 build, leaving them to try it out for a couple of hours to make sure everything worked as expected. The DevOps team are the canary in our coal mine. If their installation keels over, we know that the build is poisonous and we shouldn’t give it to you guys. DevOps are selfless heroes. Fact.
The good news was version 1.1 behaved perfectly as the DevOps team used it to repeatedly deploy updates to Red Gate systems over the next couple of hours. So, we felt very confident that we could release it to real people. No offense intended, DevOps folks.
All we need to do to allow external users to see that we have a new version available is to uncheck a single checkbox on our Check For Updates system. Deployment Manager installations around the world poll our server every couple of hours, asking whether there is an update available. When they find one, users are given the option to install it.
Early Warning
A key aspect of our release process is our ability to monitor and evaluate releases once they are out in the wild. The Deployment Manager Team have an electronic dashboard sat in our working area, radiating information about our release. We call it the Early Warning System.
The dashboard shows us how many users have upgraded to the new version of the product and, more importantly, how many exceptions have been hit. Deployment Manager installations (where users have kindly opted to send error reports back to Red Gate) send us information about errors they are experiencing. By looking at the overall number of users on a build and the pattern of errors those users are experiencing, we can get a very good idea of whether there is a significant problem with the product.
A couple of hours after release the vital statistics of version 1.1 looked fine. We went home, happy in the knowledge that you guys were already enjoying the code we had written and tested over the last two weeks.
We got in the following day to find the Early Warning System dashboard radiating its latest dose of feedback. What it told us was interesting; that a few users had hit an exception that we’d seen before but very infrequently (codename RGD-501, if you are interested). We could see a concentration of occurrences of this error in a short period of time, which was out of character for that issue. Coupled with the fact that the area of functionality that was involved was related to what we had changed over the last 10 days, we were concerned.
Fix it
That concern was enough to prompt our developers to start investigating the problem. They’d identified the bug in less than 5 minutes and developed a fix within the hour.
We discovered that the bug wasn’t going to be a major problem for every user, but it was going to significantly affect the new agent installation workflow. As the fix made its way through our build process – automatically updating our shared Deployment Manager environment and running unit, integration and system tests to validate it – we decided that the issue was nasty enough for us to ship a new release immediately. The new build looked good, so we started our release process again.
Less than 2 hours after spotting the problem, we had released Deployment Manager v1.1.2, which included a fix for RGD-501.
That wasn’t quite the end of the matter for us, though. Just as we have done at the end of every sprint since the project started, we got together at the end of the sprint and had a Retrospective Meeting to look back at how the last 2 weeks had gone. In that meeting we congratulated ourselves for being able to fix the problem so quickly, but we also raised the difficult issue of how we came to let a fairly unpleasant bug out of the door. As a result of the discussion in that meeting, our test specialists have decided that the ‘group-think’ that occurs during our sprint planning meetings might be affecting their testing spider-sense. Now they now have a lightweight ‘Test Planning’ discussion away from the rest of the team to make sure they know how they are going to cover the functionality we will be producing. We inspected and adapted – and hopefully got a bit better.
Let me put your mind at rest
The Deployment Manager Team try really hard to keep bugs from getting into our product. Those of us that specialize in testing – Emma and Robin – devote their time to ensuring that features are validated as they are being developed and automating the testing of new and existing functionality so we can release with confidence. Our developers – Dave, Mike and Chirayu – believe that unit testing new functionality is their duty, not a voluntary activity. They also take pride in producing maintainable, extendable code in order to minimize unintended side-effects when the code changes later. We dog-food Deployment Manager during our build process and we use a canary system to test our changes out with actual users. However, as you can see in this picture, we are human (apart from before our first coffee on Monday mornings, but that doesn’t count) and occasionally bugs are going to get into Deployment Manager.
When these bugs do sneak in, our ‘little-and-often’ release cadence coupled with the constant feedback we receive from our users’ systems, means that we can spot those bugs, identify fixes to the code (because what we worked on last week still fits in our heads) and get a repaired release out swiftly.
Automated Deployment, Development, Red Gate Deployment Manager, Software Delivery
We’ve just shipped a new version of Deployment Manager which includes a new command line tool to create and publish packages for Deployment Manager.
The first version will make it easier to bundle up the contents of a folder into a nuget package without using a .nuspec file. To use the command line tool, just navigate to the Deployment Manager directory and fire up RgPublish.exe. We’ve spent a lot of time working on the help and error handling, so hopefully you can just run it, read the help in the executable (run the .exe with no args) and get started. We’ve also created some documentation to help you get started. Anyway, here are the release notes:
What’s new in Deployment Manager v1.1.6?
- New commandline tool for creating NuGet packages of a given folder. For more information see our support pages
- Deployment Manager executable is no longer reliant on other dlls
- Bug fixes
Download Deployment Manager 1.1.6
.NET, Automated Deployment, New version, Red Gate Deployment Manager, Software Delivery
We recently released Deployment Manager 1.14 which simplifies the download and agent install process. Deployment Manager now consists of a single download and allows you to easily install agents from the “Add Machine” dialog.
What’s new in Deployment Manager v1.1.4?
- Download the Deployment Agent installer from the Add Machine dialog in the Deployment Manager Web Interface.
- Improved Powershell logging. Deployment Manager now captures all of the output from the powershell scripts that run as part of a deployment.
- Bug fixes
We are currently developing the user roles and permissions feature to give you more control over your deployments with Deployment Manager, and we are looking for people to help us shape this functionality. We’d really like your input to get a better understanding of what you need.
Please take part in our survey about user roles and permissions in your organisation and get the chance to win a $50 Amazon voucher. It should only take 5 minutes of your time and would be a great help to the Deployment Manager team.
As always, we appreciate your feedback and look forward to hearing from you.
Many thanks!
Ben Rees has just posted a meticulously detailed walkthrough of how to set up Database Continuous Integration for SQL Server using Red Gate Tools, Atlassian Bamboo and GitHub. This is really useful if you’re thinking about using Deployment Manager alongside a Continuous Integration environment.
This post explains how to install Red Gate’s Automation License for Continuous Integration on Atlassian’s Bamboo CI Server so that you can start running Continuous Integration builds for your SQL Server databases. This will allow you to automatically trigger unit tests and integration tests on your database whenever you check in changes to Red Gate’s SQL Source Control. It also makes the latest version of the database continually available for deployment.
The steps:
- Source-controlling your database in GitHub with Red Gate SQL Source Control
- Installing sqlCI.exe to build any database changes you make
- Installing an evaluation of Atlassian Bamboo
A subsequent article will detail how to implement tests for those changes and how to deploy the updates to production, using Deployment Manager.
You will need:
- Access to a SQL Server instance and SQL Server Management Studio (SSMS)
- SQL Source Control
- A GitHub account and Git set up on your local machine
- See https://help.github.com/articles/set-up-git for instructions, and http://windows.github.com/ to download the Windows client
- The Red Gate Continuous Integration build scripts Click
on this page and save the sqlCI.zip file to your machine
- The Java Runtime Environment (see the end of this article for further information) Click
on the page and select the appropriate version.
Read the full article over at Simple Talk.
Development, Software Delivery, SQL
The Deployment Manager team are working on adding user roles and permissions into the product so that you can deploy your application and database code simply but above all securely.
We have to admit it’s a project that’s being approached with a fair degree of trepidation. Why? Because it’s something we really want to get right.
In the interests of full disclosure we did have a version of user roles and permissions built for Deployment Manager. On paper it ticked all the boxes, but in usability testing it failed. Badly. It just wasn’t good enough for our users or for the Deployment Manager team to give it their stamp of approval so it was never shipped.
Users told us they wanted user roles functionality that is ingeniously simple to set up, regardless of whether they worked in a small development team or a large enterprise. They also wanted a solution that would scale well as the number of users grows within the company.
There is no such thing as too much user feedback and we would still like your input into this important story. Which deployment problems would you like the roles and permissions to solve?
Please add a comment and have your say.
Automated Deployment, Development, Red Gate Deployment Manager, User Experience
