Patterns of Enterprise Deployment: Versioned Contract

This is part of the Patterns of Enterprise Deployment series.

Summary

A contract is my word for anything that forms an agreement between two systems. It could be formed by database schema, message format or API.

You have a new version of a system that uses the same technologies as before but in the new version there are changes of usage or naming that makes the old version and the new version incompatible and confusing to compare. In order that you don’t have to do a BigBang deployment, your system continues to support both contracts. The new system maybe distinguished by a new name, version number, address, port number, GUID etc. Under these contracts, you may or may not decide to have one code base supporting all the requests. Ideally, there would be a single source for the data if the same data is accessible  via both contracts.

Many systems for doing remote invocation support VersionedContract as part of their architecture; e.g., DCOM, RMI, CORBA, .Net Remoting, .NET WCF.

Difficulty

Low

Advantages

• Simple, quick to do
• maintains old interface, callers don’t need to update

Disadvantages

• leads to cluttered system interfaces
• sometimes it just isn’t possible to clean out the old callers; that leaves you with version 2 and 3 as well
• support burden can be onerous as the “old way” holds you back

Use when

• You have a small new feature to implement and you can re-use the old contract as the implementation
• it’s time to make a clean break with an old contract that is being stretched too thin
• you just don’t know who calls your system or when

Don’t use

• When you have already used it once.

My experiences

The classic instances of this, for me, come from the windows API. The one that stands out in my mind is the DCOM call CoCreateEx. The windows AP is full of this sort of thing because they fall under the “you don’t know who is calling you” advice. That is the one thing that MicroSoft do better than anyone else: backwards compatibility. They can support so many flavours of OS and the same damn code keeps on working. But you also see the burden of all those changes!

Patterns of Enterprise Deployment: Automated Deployment

This is part of the Patterns of Enterprise Deployment series.

Summary

An application to take the pre-built executable deployment package and dump it onto the target system in the correct state. The AutomatedDeployment may be as simple as a shell script to copy the binaries from your development machine to the test server; or, it might be consuming the output of a system that does a full clean build and migrates it onto the production server. This is somewhat different from an InstallerApplication as there is no interactive element and the emphasis is on rapidity and simplicity.

Difficulty

Medium

Advantages

• repeatable
• automation means you can concentrate on something else, especially if it is time consuming

Disadvantages

• a fair amount of upfront work
• slow to react to changes to the architecture of the system
• can be dangerous; manual changes take time to be destructive; a deployment script that goes awry can wreck servers in seconds
  

Use when

• there are several steps in the process of moving built executables to the running server
• you perform the deployment many times; you may be deploying to a test server 20 times a day

Don’t use

• When your project is changing so rapidly that you don’t know what it will produce
• if you haven’t tested the automation very well and the target environment is unstable (e.g., many target machines and many versions of OS or other people are also using manual deployments)

My experiences

Coupled with a DeployFromSourceControl this is a good thing to have for agile developers who like to build the head of the trunk and stick if on the server. I also use it a lot when I’m working with a test server; i just want to grab the binaries that I just build and restart the service on the remote machine. It takes a few minutes to knock up a powershell script to do this, but it saves so much frustration and really, drag-n-drop is very slow! But, this really isn’t the same as a production quality script. If you have to use a script to deploy it is best if that is the only method to deploy the application; otherwise minor changes will creep in when people don’t follow the same pattern and the script won’t work properly. Worst case it will half-deploy and leave you with a system that you will have to recover by hand.

Patterns of Enterprise Deployment: Deploy From Source Control

This is part of the Patterns of Enterprise Deployment series.

Summary

DeployFromSourceControl is used when you are wish to create deployed packages only from source controlled code. Normally the pattern will be implemented by a system that will ensure that a known version of the source is obtained – often the latest – and then build into a deployable package. Many levels of sophistication are employed from batch scripts to full-blown event-driven service centres with web front-ends and deep integration with work-tracking project management systems that produce full audit trails.

Difficulty

Medium up to a full life’s work

Advantages

• Repeatable
• if it isn’t in source control then it won’t get built so there is no danger of losing changes when you re-deploy
• you will, with varying levels of effort, be able to reconstruct any package that you build by examining source control timestamps

Disadvantages

• a fair amount of upfront work
• slow to react to changes to the architecture of the system; you need to make a second change to the deployment package builder
• can be slow; developers must check in then wait for the changes to be build from source control

Use when

• building the deployment package from source control is almost always essential on a serious enterprise project. In any case, this is valuable intellectual property; check it in!

Don’t use

• When your project is changing so rapidly that you don’t know what it will produce

My experiences

This is a crucial one for any project, but don’t feel that you need to be constrained by the hoary old “build script”. As long as you are only building your deployment packages from something that is in source control you can do anything you like.  One nice twist that I’ve always wanted to try is to use a continous integration system – like CruiseControl.Net – to provide the built artefacts. You know that the stuff is in source control, just that it is a little fresher than normal! If you don’t like this and think that it is too unstable for releasing then you can run the CI build on a very stable branch that you only check into by merging in from the development brnaches.

If you can get a dedicated system for this then when you start integrating with the rest of your development process tools then things really start to look sweet. If you can get the whole TFS stack running well, then Team Build provides a huge amount of integration with work items and changesets/checkins and produces reports for each build in the staging area and means of tagging the build that is ready for deployment.

See also

AutomatedDeployment

Patterns of Enterprise Deployment: Just Copy The Binaries

This is part of the Patterns of Enterprise Deployment series.

Summary

JustCopyTheBinaries is what you do when you don’t have an enterprise deployment problem at all. The binary – or other executable files like javascript files – are simply constructed on the developer machine and copied using the file system to the machine where they will be used.

Difficulty

Very Low

Advantages

• quick
• easy
• always works; even if you have to craft a special hack on your laptop when the power is off in the server room

Disadvantages

• little or no control, auditability, repeatability
• development machines are not the place to make clean builds
• When the developer leaves the project or their box blows up, then deployment is difficult

Use when

• you don’t need anything else and you are working on an uncontrolled or or pre-alpha prototype project
• all the work is done on one machine

Don’t use

• When you are creating a real system, even for version 1.0

Patterns of Enterprise Deployment: Introduction

Deployment is a neglected topic. It sits on the project diagram as the line that separates development work from support work. It is rarely given any time in development and even less for the testing. Just as Continuous Integration stresses that if you can’t build your project, then you don’t have a project; if you can’t deploy your project then you don’t have anything.

This will be a set of articles discussing the topic of enterprise deployment; not the kind of thing that you do on your own website where you JustCopyTheBinaries. That might work for the first version where you don’t have any users but it won’t be any good when you have a mesh of consuming systems and users in 4 times zones. It just isn’t good enough to tell people who have systems that have just stopped working on quarter-end that “Oh yes, that was a breaking change”.

Often, in the enterprise, you don’t even get the luxury of a trivial v1.0 deployment. More often than not, you have to replace an existing system; but support its bugs for a while even though your new system is event-based and the old system runs as an overnight batch. You just have to make it work, real people doing real work are depending on these systems to actually make the money that pays for your servers. Shocking, I know.

And deployment is something that never stops. You can’t “finish” the project with a deployment. In the enterprise world there are always new features and new servers in new offices that need a deployment; if you don’t have the deployment under control then you will be wasting your time and your customer’s time; with downtime and debugging.

Maybe, downtime isn’t the problem for you; maybe you don’t have a lot of timezones so you have all night, every night to do what you want; but you do have a set of users who want new features every month. Maybe you work on a non-critical application like a social web site; you are on 24×7 but you can tolerate downtime but the website can’t be off for more than 10 minutes; you have to ship new features every day and you have a development team who demand that the new work goes live from source control to the production system. If you have to do that, you have to not only have a system that allows you to DeployFromSourceControl but you need an AutomatedDeployment.

So, this set of articles will deal with a vague set of problems from the actual “go live” moment to how to architect your applications so that they can smoothly take over from a predecessor system. The systems under consideration will range from databases to web services to client applets.

This set of articles was inspired by the Martin Fowler article on a type of deployment that he called the StranglerApplication. It seemed to me that there were many such good tricks that could do with codifying.