In this series I think that there will be two types of pattern. The architectural patterns will focus on how you design yourself out of a difficult situation involving the deployment of software. The behavioural patterns will — obviously — be habits that will help.
The biggest concern of patterns is to recognise a problem that occurs again and again. Once a repeated problem has been recognised, it is often simple find a solution. The difficulty is recognising problems that are fundamental rather than incidental. It might also be possible to design a solution to problems that seem to be bad behaviours, if they are fundamental. However, this kind of pattern is hard to spot without breadth of experience and the time and inclination to be retrospective.
For instance, if you create a piece of software without a good redeployment strategy and that software has a lot of bugs, you might not come to the conclusion that you needed a deployment solution; you might just think that — in this case — there were a lot of bugs. Next time, you think, I won’t make so many bugs so I still won’t need a deployment system. This can happen over and over again; some people are reluctant to see that things are repeating and may think that concentrating harder is the answer.
The opposite can also be true; some people may do a thing badly and then think that either they need a new pattern or new piece of software to help; or they may think that “that way of doing things doesn’t work” when, in fact, other people can make it work. This can manifest itself as being “pattern happy” and trying to apply patterns when they aren’t appropriate or too many patterns at the same time. For instance, it may be the case that someone wants to make changes to an interface; they make elaborate plans for logging and tracking changes; for rolling back the application and for publishing new versions of the schema. Then when the application is deployed they find there is only one other user, and they don’t even care about the changes! It takes 5 years to learn how to use patterns, and it will take another 10 to learn when not to use them.
These could be described as habits, but I want to put them on a level equal to patterns. Any habit that we have, and we don’t know why we have it, is a superstition. I think it is worth the effort to examine some of them and codify when they will and won’t work. There are some behavioural patterns that you might want to create a software solution to; to try and automate away the need for a human to be disciplined or precise. Computers are good at those things, people generally are not. However, just as there will always be a need for infantry, there are some things that need to be adaptable; and computers are bad at that (largely because it is so hard to make software adaptable). Some of the behviours will require interaction with other people; for instance, CommunicateChanges requires software developers interacting with DBAs or the business stakeholders. Some will require nothing more than concentration while you are actually deploying; for instance HumanLogger. All of them require intelligence to be applied successfully.
The problem with architectural patterns of all types is that they can seem like a sledgehammer to crack a nut. For people who are haven’t seen how complicated things can get in software that develops over years, they seem excessive and rather abstract. Implementing something which solves a problem that you don’t have is hard to justify, and rightly so. However, like OO design, if you understand the patterns well it should be no harder to use a pattern than to do it in a “hacky” way. Or at least, not much harder. It is quicker to hack, but not for long. It may take an hour to create a SetupApplication, but as soon as you have used it twice it has paid for itself. And as soon as it has prevented you from screwing up a manual installation it has paid for itself 10 times over.
Of course, like anything else, if you don’t know how to implement the pattern you will be fighting the tools and that can be an enormous time sink. If you don’t know what the tools already support you might be reinventing the wheel, and doing it quite poorly. However, don’t be afraid of DIY. You might be pulling off some obscure stuff with DCOM deployments by using scripting and all sorts of hacks and then someone comes along with 10 years in the DCOM game and says “Didn’t you know that you can…” but as long as you are conceptually correct a) you won’t have done a bad thing and b) it might be possible to replace your version with the “build in” version. And one other thing: even though many technologies come with deployment “magic”, in my experience making them work isn’t always easy and the hand-rolled, home-made version is more reliable and understandable because when the “magic” fails it fails stylishly and leaves you with a mess; but that might be because I’m not one of those fabled experts, just a luddite with a penchant for shell scripts. 😉
I will be including some patterns that are obvious; for instance SetupApplication. Anyone who has used a computer in the last 10 years will recognise that. However, it is worth mentioning to put it in context with other solutions. Also, it needs discussion about when you shouldn’t use it. My intention is to present all the options, not just the “interesting” ones. Using the right pattern doesn’t mean using the coolest one, or the most enterprise-y one.
Having said that, one thing to consider when architecting deployments is that small applications can become big applications. Small user groups in one office can become international, multi-timezone, multi-language groups in just a few years. And if you think that a few years is a long time then you need to adapt to the speed at which applications change in serious enterprise infrastructures. Once an application’s contract has been woven into the fabric of the enterprise in several other applications it is then in messages and log files and web services and database schemas and reports and so on. Every one of those is maintained by a different group with a different release cycle. Not all of them will want the changes that you are making, few of them will have anything like adequate test coverage for you to be able to test before you go likve and none of them will have any resources to make the change.
If you expect to make a serious change in the public contract of an application you better start thinking about how you will deploy it before you go public. If you don’t you may find it difficult to retro-fit a deployment methodology. That is the point of this book; deploying can be harder than it looks and a small amount of thought may save a lot of pain later. Thinking about deployment before you have to deploy, just a little bit, can really pay off.
Patterns in the wild
Mostly you rarely see patterns in their purest forms. The point of a group of patterns is to allow us to create a set that can be built up and combined to form any solution to fit any technological or political situation. One example that I’ll discuss in another post is the Ubuntu Add/remove programs feature as it contains several patterns.