Good Software Deployment Practices

I earlier mentioned my software deployment goal: Boring Is Good!  Over several posts I will cover some of the things that can help accomplish that goal, starting with the very basics.

 

Basic practice number one, coming up!

Use Source Control

This one seems obvious to many developers but not to all, especially as we change the discussion from standard (Java, c#) code into database schemas and into other technologies where development is done via point-and-click rather than writing code.  There’s often a “publish” button in the Integrated Development Tool that looks so tempting…and it’s great for local testing and for small projects, which is what it was intended for.  But for larger projects, the first rule is unbreakable:  other than on your own machine, the deployment process begins in the source code library.  Nothing goes to production that didn’t originate there.  That means nothing!

“Do you really mean that if Brad, our technical writer, needs to update our release notes (a .pdf file), he has to email it to someone who can check it into source control before you will deploy it?  Isn’t deployment in this case just a file copy to a web server?”

 

Read the rest of this entry »

Boring Is Good

I find a lot of excitement in being boring.  Really!

But I suppose I should say something about the context of that…

I’ve been spending a lot of time over the last couple years focused on the build/deploy cycle in a nearly-Agile environment (still working on the Agile part).  I’ve been involved in deployments before but for the first time I’m in an organization that really wants to do it well, and is willing to invest in doing so.

We have certain goals:

  • Have productive development and testing environments
  • Have boring deployments into each environment, including production

And here are the characteristics of boring deployments:

  1. Little impact to the end users
    1. Minimal downtime
    2. No errors introduced by the deployment process
    3. Up-to-date help documents, customer service preparation, training infrastructure, etc.
  2. Not a fire drill
    1. Few people needed to run the deployment process
    2. Minimal time spent gearing up for deployment
    3. Quick deployment time
    4. Low risk of having to call anyone else during deployment (or afterward) to deal with issues
  3. WYSIWYP (What You See Is What You Planned)
    1. Expected features are present and working
    2. Bugs (well, most of them) known
  4. Worry-free
    1. Managers come to expect few problems related to deployment (unfortunate side-effect:  they then forget its importance and difficulty)
    2. Developers, including Quality Assurance staff if the organization has such positions, expect the software to work as well in production as is did in all the test environments
    3. People take vacations without having them interrupted or preempted by deployment issues.

As you can see, I think that the software deployment process should involve the whole organization, not just IT Developers and/or IT Administrators.  I’m (mostly) a technical guy and expect to write more on what this means to developers and administrators.  But I think it’s good to put it in proper organizational perspective.

And it’s good to be boring!