I posted last week about the awesome new features, but the big headline features are the new user permissions control and the new completely free Starter Edition. We’ve also managed to squeeze in a small number of bonus features which weren’t in last week’s update:
- Initial website creation: gives you the ability to create the application pool with all the appropriate settings.
- Audit trail: Deployment Manager 2.0 now identifies who ran each task.
- RgPublish.exe can now package and publish IIS applications – including ASP.NET, ASP.NET MVC and Silverlight applications – from source code (.csproj)
You can grab Deployment Manager 2.0 from our website, or hit the upgrade button from within the Deployment Manager web interface.
Happy deploying!
.NET, Automated Deployment, New version, Red Gate Deployment Manager, SQL
After weeks of hard work- making it easier to package a database with our SSMS add-in, we’ve gone back to thinking about how Deployment Manager deploys that database package, and how we could make our current solution better to give you a smoother database deployment process.
We’ve gone back to the drawing board and come up with a list of guidelines that we think the ideal solution should have:
- It must work without needing to purchase other Red Gate tools.
- However, Deployment Manager should integrate seamlessly with any other Red Gate tools you do own with extra benefit (e.g. migration scripts created in SQL Source Control should be run by Deployment Manager).
- There needs to be a staging environment as well as a production environment in the deployment process.
- It must be trivial to work out what script is going to be run.
- The script that is run on production must be the same as the script that was run on staging.
- It must abort if the production database is not in the same state as staging, because the script may not be applicable.
- It must be possible to easily edit the script to change “how” something is deployed, e.g. replacing a drop and create with a rename, or changing the password that a login is created with (although changing “what schema” is being deployed shouldn’t be allowed).
- It must work for both greenfield and brownfield projects.
- It needs to work for both upgrades and downgrades.
But as usual, we want to hear from you!
Do you agree with these guidelines? And are there any others we have missed and you’d like to add?
Please leave us a comment below to let us know what your biggest wants from database deployments are!
Automated Deployment, Red Gate Deployment Manager, Software Delivery, Uncategorized
We’re really excited to announce that Deployment Manager 2.0 is coming really soon! Today we’re at NDC Oslo where we’ll be showing off the biggest update in Deployment Manager history. We’ve added a bunch of new features in addition to introducing a new free Starter edition.
User Permissions
We’ve finally added user permissions to Deployment Manager. It’s been the number one requested feature for quite some time, but we wanted to make sure that we got it right.
We did tons of research and the thing we heard again and again is that you want to restrict who can deploy to staging or production as well as who can edit a project. So we streamlined the UI to make these tasks incredibly easy to complete. The simplicity of the UI and the prominent nature of these permissions mean that you can have confidence that the permissions you intend are the permissions you’ve actually configured!
You can now select team members for each project, and restrict which environments they are able to deploy to. Administrators can also temporarily disable user accounts or grant temporary access to deploy to a particular environment.
New Tools
Another new addition to Deployment Manager 2.0 is the new “Tools” tab which is a convenient place to access all of Deployment Manager’s package publishing and command line tools.
We heard again and again in our research that you want a simpler way of creating packages. Getting started with Deployment Manager shouldn’t require you to first spend hours setting up a continuous integration environment and package feed!
This is why we’ve created new add-ins for Visual Studio (VS) and SQL Server Management Studio (SSMS) which make it incredibly easy to create and publish packages to Deployment Manager. All you need to do is right click “publish for deployment” to publish a package to Deployment Manager.
If you are ready to automate package creation you’ll also find our updated RgPublish.exe command line interface alongside the add-ins in the new tools tab.
Free Starter Edition
The name kind of gives it away. After talking to lots of you who are working on small projects, or planning a gradual adoption of Deployment Manager, we decided to introduce a new free Starter Edition of Deployment Manager.
The Starter Edition is great for small projects, and includes built in support for ASP.NET apps and SQL Server databases. You can also create up to 5 projects and deploy to up to 5 agents, which is more than enough for most small projects.
We’re also replacing the current per-agent licensing model of Deployment Manager with 3 editions to choose from: the free Starter Edition, a Professional Edition, and an Enterprise Edition. The two non-free editions are designed to scale to meet your demands and include advanced functionality and support. We’ll post more details next week.
Deployment Manager 2.0 is out now, download it from the Red Gate website.
-
- Getting started with user permissions
-
- Team member permissions
-
- Add a team member
The convenience of a small format device like a phone or tablet gives you greater flexibility to keep up-to-date with information that’s important to you, when it suits you. It’s no surprise that phone and tablet sales are growing at a phenomenal rate. Just take a look at the worldwide hardware sales for Q1 2013:
- PC sales are down year on year by 13.9% to 76.3 million units [source IDC]
- Tablet sales are up year on year by 142.4% to 49.2 million units [source IDC]
- Smartphone sales are up year on year by 70% to 210 million units [source Gartner]
We really want to make deployments as quick, easy and convenient as possible, so we got to thinking about deploying anywhere. Wouldn’t it be awesome to check the status of your deployments, or even deploy a release from anywhere on your phone or tablet.
We wanted to know if we could make the Deployment Manager User Experience better without needing to invest in writing separate mobile applications. The solution was to see if we could make Deployment Manager “responsive”.
Deploying from your phone?
Applications should be accessible; that is a person with or without disabilities should be able use it. Now that users have several device types at their disposal, the same should apply regardless of whether they use a phone, tablet or desktop. Making a single web site or application and making it work well on all devices is known as Responsive Web Design (RWD). Frameworks like Foundation, Twitter Bootstrap and Gumby make creating responsive applications much easier, but there are still a ton of challenges:
- Getting the [right] information to fit on all devices.
- Designing for different display sizes.
- Designing for touch.
To update Deployment Manager, which is not currently responsive, we also needed to solve a few problems we discovered in usability testing:
- To view the web application on mobile required the user to pan excessively
- The worst case was the deployment dashboard grid.
- Hover interactions were commonly used to display information.
- The application uses data tables to display information for variables. We need a way to get the tables to display well on phone and tablet.
Prototyping a new Deployment Manager
Making Deployment Manager responsive is just one of the cool ideas we needed to work on, but how could we test out some concepts to see if it would work? We hit upon a simple plan: Build a usable, working prototype within a week with one Developer, one User Experience Specialist and a load of ideas.
To start with we look the most used pages of Deployment Manager, printed them out and cut out all the user interface elements. We then spent so time working out how to lay the pages out, sticking the elements down and getting some feedback from peers. At this early stage we discovered that we could make some core workflows more intuitive and discoverable by consolidating information into fewer pages.
Next we took that feedback and created some higher fidelity mock-ups. These were to the correct size so the proportion, icon and font sizes could be evaluated. We cut these into strips and made a cardboard mock-up of an iPhone. We got some valuable user feedback about the navigation, layout and scrolling.
Paper prototypes for usability testing
The final stage was to write code and create a responsive web application. This allowed us to see the responsive behaviours and get user feedback as the user stepped through the common workflows. The behaviours we designed allowed Deployment Manager on phones to have the dashboard grid as a list and some neat expand/collapse transitions on variable tables.
The final prototype showing tablet (left) and phone (right)
So what next?
There is no doubt that we can see a huge value in giving users access to deployment information anywhere regardless of device. The prototype gave us a huge amount of feedback and the confidence that we could solve the design challenges. We’ll be finishing off these prototypes and then running more usability sessions.
We still would like your feedback about this project too:
How would deploying from any device make deployments easier and more convenient for you?
Development, Red Gate Deployment Manager, Uncategorized, User Experience
Freshly deployed today.
We’ve improved how variables work, added a duplicate project feature and, now automatically create websites if an IIS website does not exist on deployment.
Here’s the full list of changes in Deployment Manager 1.1.10:
- Copy Project – duplicate an existing project with all its steps and settings
- Variable usability improvements – improved discoverability of web application deployment variables
- Initial creation of website – if an IIS website does not exist on deployment, it will now be automatically created
- Lots of assorted bug fixes and some security enhancements.
Download Deployment Manager 1.1.10
Lastly, don’t forget about the Package Publishing Add-ins for Visual Studio and SQL Server Management Studio. The add-ins let you create and publish a database or application package directly to Deployment Manager without having to set up continuous integration or use the command line.
- Visual Studio Extension (beta) – download from the Visual Studio Gallery and documentation
- SQL Server Management Add-in – download and documentation
Thank you to everyone who participated in the user permissions survey. The number of responses was awesome and we really appreciated the detailed information you provided. These insights have been a great help to the Deployment Manager team as we work on this important new feature.
We ran a prize draw for the survey and the lucky winner was Nick Rothery! Congratulations Nick, a $50 Amazon voucher is on the way to you.
We’ll be running more surveys in the future, so please get involved and have you say in the future of Deployment Manager.
Development, Red Gate Deployment Manager, User Experience
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
