8 Tips Toward A Better Deployment Process

Posted on by | 1 Reply

One lesson I have learned over the years is not to take any unnecessary risks during production deployments. I hope that by sharing this wisdom I can help others, but I have the sad feeling that this one of those lessons that people need to learn the hard way. Unfortunately it is too tempting to “just go for it” sometimes. If it works, consider yourself lucky. When it fails (and sooner or later it will) you will regret your cowboy ways. I hope you will read on, there are some great ways to mitigate the risk of deployments.

Most of the problems that occur during deployments are caused by simple human error. Nothing serious, just plain old forgetfulness! In my experience, deployment issues usually arise because someone just forgets to do something. The thing that gets forgotten could be anything from a database script that gets missed, a forgotten view, an overlooked setting, or a .config file omission. And I don’t mean that this happens because someone is a bad developer. It’s just human nature. We are not perfect and can’t possibly remember everything.

There is no foolproof solution for perfect deployments. However, by following these tips you can greatly increase your likelihood of success. Of course, any of these practices will help but for best results, combine them all.

Deploy as often as possible

The best way to make sure nothing gets missed is to deploy often. Time is your enemy, the longer you wait, the more likely you are to forget something. During the development process we do so many things to make our applications work properly in our development environment. Sometimes we use a lot of trial and error too. As time goes on we can’t possibly remember all of the steps we have taken along the way. Following an agile process with short sprints is a great way to achieve short deployment cycles. Agile or not, try to deploy when features are complete and at major milestones. You don’t need to actually deploy to production. Use the same deployment process for all your environments. If you can’t deploy to production (there are lots of reasons for this), create a staging environment and treat it like production.

Take notes

Even if you deploy often, don’t rely simply on your memory. Take a lot of notes along the way during development and during your deployments to other environments such as test, staging, etc. Develop a good system so that your notes are there when you need them, not buried and forgotten in a notebook somewhere. I like OneNote for stuff like this.

Have a solid plan

Don’t wing it. Have a good, standard plan and stick to it. The more you follow the plan, the more likely you are to succeed.

Use a good code base

Of course, you only deploy code that you know works correctly, right? Once you know it works, don’t leave anything to chance. One of the best ways to do this is to deploy the same code to all your environments. Avoid going back to your source repository and recompiling. So many things can go wrong once you do. After you deploy to your test environment and everything has been verified, you should use the exact same files (.dlls, script files, whatever) and deploy them to prod (or your other environments). Of course you will be probably need to make configuration changes, that is often unavoidable.

Watch your timing

Find a time that works good for you and your team. Different businesses will have varying constraints on when they can do production deployments so you will of course need to work within those parameters. But I definitely have my preferences for when I would choose to deploy. I like to deploy first thing in the morning when I am fresh and thinking clearly. If something goes wrong, I have a lot of time to fix it. Also, I’ll have access to other people/resources for help if needed. If I deploy at the end of the day and something goes wrong I’ll be stuck working at night to fix it. That is bad because a) I’ll be getting tired and might not think clearly, b) I won’t have people around to help and c) I won’t get to have dinner with my kids. I also like to deploy midweek. Monday mornings are bad because over the weekend I have forgotten things already! Monday is a great day to put final preparations on a big deployment. Fridays are bad too. Because if things go wrong, I could be stuck trying to fix things over the weekend!

Automate your process

I don’t trust myself or my memory much. The best way I can protect myself from me is to automate my deployments. Once things are scripted, automated and tested, I have greatly increased my chances for success. Most of the other tips I have listed are fairly easy to implement, but putting together an automated deployment can be a big project all in itself! Depending upon your project, automated deployments can be quite complicated and there is a lot to learn in this department. There are lots of great build and automation tools out there to help such as MSBuild, NAnt, TeamCity, Hudson, CruiseControl, etc. I’ve used a bunch of different tools over the years and now I am using Team Foundation Server 2012. I’ve found it to be the easiest and fastest of all to set up for my web project deployments.

Practice your deployments

Practice makes perfect, right? Unfortunately with deployments, just when you get your process working smoothly there will be some big change that will require you to modify the process anyway. But practice will definitely increase your chance for success. I even practice my automated deployments, that is the reason to have a staging/faux-prod environment. And practicing really comes in handy when it comes to database changes. It’s great to have a staging environment set up just for the purpose of practicing deployments. To practice, get your staging environment set up to match your production environment including .dlls, html and script files, databases and other resources. Then run through your deployment process on staging. Once complete, test your application to make sure everything works. If something went wrong in the deployment, don’t patch it. The best thing to do is roll back the entire staging system, tweak your process and run it again. You do this as many times as needed until you get everything right. Then you are ready to repeat your steps in your production environment. Of course, the more you automate, the less likely errors will be. But don’t assume that just because you have an automated system you don’t need to practice too.

Start soon

Lastly, do not wait to implement this process. Many developers wait, thinking that they’ve got a long development cycle and won’t be deploying to prod for a long time, maybe months down the road. When I start a new project I begin working on the build/deployment automation right away. I also make sure there are tasks created for this process. Making this an official deliverable buys me time for this work which can definitely be time consuming. And if you don’t get this work done early, you might not get to it at all. When a project is almost complete and the delivery date approaches, you will never find time to get your process in place. You will then be stuck with an error prone deployment that not only keeps you worried but will likely cause you to work on weekends fixing deployment issues.

 

A solid deployment process takes a lot of planning and work. Of course, if you have ever been on the wrong side of a bad deployment you know that all the planning is worth the extra effort! Good luck.

Visual Studio 2012 Tip: Add Reference Dialog

Posted on by | 1 Reply

 

Lately I’ve been speaking at local user groups about many of the exciting new features in Visual Studio 2012. Since there is so much to know and learn about VS 2012, I decided to create a collection of blog posts with many of the tips. This collection of posts will include features that are new to VS 2012 as well as some existing features as well. To view all of the VS 2012 tips posted so far, click here.

Visual Studio 2012 has got a lot of great features. Some of them are really innovative and interesting. I don’t think of the Add Reference Dialog improvements as anything but “why in the world did this work so poorly before?”. I’m guessing the Visual Studio team had some reason but let’s face it, the old Add Reference Dialog just plain sucked. One of the biggest problems with it was that it was very slow to load. I’m happy to report that the new Dialog loads really fast! Try it out, I am sure you will be please with the results.

Access it as you did before, right click a project and then click “add reference”:

image

Like I said, it loads up really fast. As you can see, in the middle section is the complete list of assemblies from the .net framework. Note that the items with checkmarks have already been added to my project. Just as you’d expect, you can add references to installed.net assemblies, other projects in your solution and COM Libraries. And of course, you can browse your system for other .dlls.

When you use this the first few times I expect your get bit by the same snag that I did (and still do sometimes). See the screenshot below… Notice that I clicked on Microsoft.Build to add the reference. You can see it highlighted in blue. If I click the OK button I’ll be disappointed with the results as my reference will not be added. What is needed is either to double click the item in the list or click the checkbox itself. Either way you’ll see the checkbox is then checked. Now you can hit OK. By the way, unchecking an item in the list will remove it from your project.

image

 

I hope you find this tip helpful. To see more VS 2012 Tips, just click here.

Visual Studio 2012 Tip: Better Event Handler Code Completion

Posted on by | 1 Reply

Lately I’ve been speaking at local user groups about many of the exciting new features in Visual Studio 2012. Since there is so much to know and learn about VS 2012, I decided to create a collection of blog posts with many of the tips. This collection of posts will include features that are new to VS 2012 as well as some existing features as well. To view all of the VS 2012 tips posted so far, click here.

I think (I hope) it is a well-known fact that Visual Studio will automatically complete your event handlers for you. The problem is, I’ve never liked the way it did this and I always went in and cleaned them up. Not any more!

What am I talking about? Here’s a sample. In this case, I have a class Foo that has an event SomethingHappened.

    public class Foo
    {
        public event EventHandler SomethingHappened;

        public void OnSomethingHappened(EventArgs e)
        {
            EventHandler handler = SomethingHappened;
            if (handler != null) handler(this, e);
        }
    }

In another class, I have an instance of Foo named foo. To wire up that event, all I need to do is type:

foo.SomethingHappened += [TAB][TAB]    (I hope you know that I mean hit the “tab” key twice Smile)

When you do that in Visual Studio 2010 (and prior), you will get the following results:

public class SomeService
{
    private Foo foo = new Foo();
    public SomeService()
    {
        foo.SomethingHappened +=new EventHandler(foo_SomethingHappened);
    }

    void foo_SomethingHappened(object sender, EventArgs e)
    {
        throw new NotImplementedException();
    }
}

What happened here? Visual studio added a method (foo_SomethingHappened) and attached it to my handler for me. Thanks!

But this gets even better when you use Visual Studio 2012! Doing the same thing will get you this:

    public class SomeService
    {
        private Foo foo = new Foo();
        public SomeService()
        {
            foo.SomethingHappened += foo_SomethingHappened;
        }

        void foo_SomethingHappened(object sender, EventArgs e)
        {
            throw new NotImplementedException();
        }
    }

 

OK, it isn’t thatdifferent. But the “new EventHandler” text is not there. It isn’t needed, of course so it rightfully isn’t there. I try to remove as much extra text from my code to make it more readable and I’m glad the Visual Studio team is thinking along the same lines. Actually, a lot of the time I clean this up even more by removing the object name from the event handler, in this case “foo_”. It might be needed sometimes, for clarity or, of course, if you need to specify which object the event is for. But in this case, I think it is just overly verbose. I prefer this:

    public class SomeService
    {
        private Foo foo = new Foo();
        public SomeService()
        {
            foo.SomethingHappened += SomethingHappened;
        }

        void SomethingHappened(object sender, EventArgs e)
        {
            throw new NotImplementedException();
        }
    }

I hope you find this tip helpful. To see more VS 2012 Tips, just click here.

Visual Studio 2012 Tip: Color Coded Status Bar

Posted on by | 1 Reply

Lately I’ve been speaking at local user groups about many of the exciting new features in Visual Studio 2012. Since there is so much to know and learn about VS 2012, I decided to create a collection of blog posts with many of the tips. This collection of posts will include features that are new to VS 2012 as well as some existing features as well. To view all of the VS 2012 tips posted so far, click here.

A lot has been made over the colors (or lack thereof) within Visual Studio 2012. I wrote a blog post about it back in May, 2012. While many parts of VS don’t have color, there is one item that had color added. Did you notice the status bar at the bottom of Visual Studio? Is it purple? Is it blue? Or is it orange? The answer is yes, yes and yes. It simply depends on what you are doing.

When you first open VS, the bar is purple. This indicated that you have no solution open.

image

After opening a solution, the bar will be blue.

image

And if you are in debug mode, the bar is orange.

image

If you are like me and often have multiple instances of VS open at once, you may find this useful!

 

I hope you find this tip helpful. To see more VS 2012 Tips, just click here.

It’s Time to Learn JavaScript

Posted on by | 3 Replies

ASP.Net Developers, it is time to change your attitude towards JavaScript. I know you hate it. I used to hate it too. But I’ve come to terms with JavaScript and now actually quite like it! It isn’t my favorite language but I’ve been working hard to understand this important client side technology.

Please don’t be offended by this post. I know I have lumped all ASP.Net developers into one category here. I know many of you are in the same place as I am, moving quickly towards understanding Javascript. I am, however, speaking to a large group of .Net web developers who have not yet started their journey. You know who you are.

I’m a C# MVP and, prior to this past summer, I spent 3 years doing Silverlight development. I truly believe that Microsoft was on to something with the concept of Silverlight. Like many developers, with regard to client side web development, I knew there had to be a better way to do things than JavaScript. Silverlight was a great attempt. It wasn’t perfect but the concept was good. Heck, I thought that anything that saved me from JavaScript was a good thing. I don’t care what anyone says, JavaScript is not the best solution to client side programing. I think we could have had better. Silverlight was a good try but people didn’t embrace it for various reasons (I won’t get into that in this post). Well here we are now and Silverlight is pretty much toast. It seems like Microsoft has thrown in the towel and isn’t trying to replace JavaScript and I doubt anyone else will pick up that fight.

For the past 8 months or so, I’ve been back doing “traditional” web development. I’m quite happy to be in the world of asp.net MVC with HTML, JavaScript, and CSS. In the past few years, a lot has changed. Three and a half years go, when I last did this sort of work as the main part of my job, jQuery was gaining a lot of traction and was becoming widely accepted. But not like it is today. Today, many developers incorrectly use the words JavaScript and jQuery interchangeably (which is actually quite annoying). And as great as jQuery is, there are a ton of other great JavaScript libraries to help us developers. Patterns like MVVM and SPA have gotten quite popular. And I’ve learned that there are some other great patterns that can be applied to JavaScript development that can make the experience much better, especially for a pattern-happy OO developer like me. So I have been reading up on and practicing using closures, the revealing module pattern, prototypes, MVVM, dependency injection, and more. And I haven’t even started with TypeScript which looks very interesting, to say the least. And I should also mention that products like Visual Studio (and many plugins too) have come a long way to finally embrace JavaScript and have started to treat it like a first class citizen.

In addition to the fact that doing client side development is much better these days thanks to frameworks and tooling, our users have come to expect a richer experience from web sites and applications. Users want web pages to be useable and responsive and, dare I say, “nice to use”. And so, fellow ASP.Net developers, the time for faking our way through JavaScript is over. I have put a lot of effort into learning more about JavaScript. I’ve started treating that part of my job as seriously as I do C#. I don’t expect that I’ll become some kind of JavaScript Ninja anytime soon, but I’ve realized that JavaScript enhanced UIs are an important part of my work. I’m giving JavaScript respect and I’ll expect other developers to do the same. No longer will I accept a job candidate’s dismissive answers about their knowledge of JavaScript. “Yeah, I can do a little JavaScript but I don’t like it” is no longer a valid answer to an interview question. JavaScript is an important aspect of our jobs as web developers and it isn’t going anywhere, at least not for a while.

I talk about this story a lot… few years ago in a team meeting the developers were complaining about their struggles in writing JavaScript which was becoming an important aspect of our web solution. Our manager, who is a really smart guy and still a friend of mine, asked a few questions that made a big impact on me. First he asked, “How many books have you guys read about C#?” The response varied across the team but we had all read a bunch of them. He followed that up with the knockout punch… “how many JavaScript books have you read?” The room was pretty quiet. Most of the group had read none. At least I had read one, but I was wasn’t much different than the group. JavaScript programming was part of our job but yet we didn’t take the time to learn it. And through my career I have found that most ASP.Net developer’s (myself included) experience with and towards JavaScript was pretty similar.

The age of treating JavaScript with disrespect is over. It’s a necessary part of our web solutions. And as I said earlier, the frameworks and tooling have gotten much better. So now is the time to learn it, embrace it, use it, and succeed with it.