Chances are, we have probably all experienced nightmare release procedures. Put it this way, you’d be very fortunate if you hadn’t! As projects mature, release procedures tend to get better, sometimes far too late in the life cycle of the project, though. The trick is to aim for getting the release management working as early as possible, ideally sometime in the Inception phase. The earlier the release management works, the more stable the architecture will tend to be. Let’s take a look at release managing a “Hello World” candidate architecture as an example of a starting point for the project release management.
I was horrified when some years ago I first joined a mature dot com and found that the release management procedure consisted of something along the lines of the following:
· The main tester did a diff on the files between the development environment and the live environment, and then zipped up all the files that were different and copied them into the test environment.
· Occasionally some developer had forgotten to check the odd file in and emailed it to him, or sent him a file he’d just improved a little more or recently debugged!
· The tester tested them for the rest of the day and into the early hours of the morning, under huge duress mind you, because, as usual, the developers had long overshot their deadline and management were pressurizing for a release into live. Testing was supposed to have had a week for this work.
· Finally, after minimizing the bugs and deciding what could be released, the tester bravely herded the working files into a zip file and mailed it off to the live administrator in another country along with an email on how to install this particular release.
I may have oversimplified the process a little, but believe me, it wasn’t much better than that. All of the dedicated version controlling, checking in and out, all went right out the window once the mad rush to build, test and release happened. There was no concept of base lining, no integration management or branching, no defect tracking, no automated builds, and not even proper configuration item identification. It was all manual, on the fly “I’ll remember what I did” and “Oh, I must remember to tell Joe in the morning that I altered one of his base system components.”
Architecture Flawed Means the Whole System is Flawed
Needless to say, because the build and release management process were so ad hoc, we never dared change too much in the Architecture, because quite frankly we were too scared the whole lot would come crumbling down around us, and that we couldn’t easily revert back to an earlier working version.
We knew from an early point in the life-cycle that, there were some method calls that were bypassing layers of the Architecture. You know the type of thing, a presentation layer object calling the database directly and bypassing the business logic and permissions, etc.
Once you are in that predicament, where you can’t rely on your implemented Architecture to be stable and your system is live, everything from then on that you add to your system, you do at a disadvantage. You start devising design work-a-rounds because the architecture is not as you’d like it to be. You do everything slower because you want to be that much more careful. It all gets more complex than it should be too. You now have more items in your system which makes it even harder to refactor the Architecture. It’s a cumulative catch-22, which can spiral right out of control if you let it. It all got a lot better over time and we survived to tell the tale.Strive to Build: A Real Simple, Real Early "Hello World" Candidate Architecture Foundation
What was learned out of the above experience and other experiences subsequently, is that the best way of getting the release management going, as well as bedding down and proving an Architecture, is to let them both start off real simple real early. This reminds me of Integration Math some years back: As “release management tends to t=0, architectural stability errors tend to 0. Where t = time along a timeline”. This is a recipe I’d suggest. Sometime very early in the Inception Phase of the project, if you are the project manager, have your configuration manager, define a directory structure for the project and work on the release management in the configuration management plan. Simultaneously have the tool-smith set up your chosen configuration management tool. Time box the activity into an iteration so that something has to be working after so many days or weeks.
In parallel, while they are doing that, have the Architect start thinking about the generic Architecture they are going to use. Will it be J2EE or .NET? Will they use messaging middleware? Will there be any off-the-shelf software that will need to be part of this? Have the architect task a designer / developer to build a really simple “Hello World” model and application in the estimated target environment of your project.
Try and build your “Hello World” candidate architecture to make use of all the main layers of the application architecture (i.e., build an application which takes as input from an edit field on a screen in a browser the words “Hello World”, pass this info to your component in your business layer that contains an object which deals with “HelloWorlds”). Next, have that business component persist this information into a table in the database layer table called “Hello_World.” Time box this activity so that in the same timeframe, something gets designed and built. Obviously make sure there the architect team brings their code into the configuration management system as soon as it has reached a useable point.
Now make and build this “Hello World” system, and deploy it on the testing environment. If the testing environment hasn’t yet been setup, then execute it on the development environment.
Prime the Pump
What we have achieved by following the recipe above is:
· To get the development cycle going. It overcomes all sorts of inertia and deliberating by concentrating on something relatively simple first.
· The development cycle can always be enhanced in subsequent iterations over time.
· What this does is to force people to keep it simple and not get lost in the wood for the all the trees.
· It makes them start at the beginning, all focus on a simple starting point and not assume anything.
· It forces an early reporting mechanism for seeing problems, risks and bugs out the build.
· It forces an early staged handover into testing and live production.
· Now we have a point of departure for enhancements to the architecture.
· We also have a fantastic placeholder where our first one or many architecturally significant main use case scenarios can be implemented. Be it in the Reference Architecture Model implementation you just built, or the real actual system implementation you decided to start from scratch.
Conclusion
Often doing something simple just to get the ball rolling is what is needed to unclog some of the blockages, real, perceived or otherwise. Once the pump has been primed, the architecture team can get into their typical architectural problem solving of the candidate architecture and tackling the highest risk hardest things first under way. The configuration management can get on with enhancing the build and release management strategies according to their tactical plans.
By the time your project gets into and completes the elaboration phase, you will be correctly placed to do the serious business of building your system properly, by enhancing it in allocated use cases increments at a time.
