Build Management and Monolithic Systems

The Problem

I've recently started working for a new company that operates in the insurance sector. They are an Oracle outfit with a few other technologies thrown in for good measure - there's even a mainframe. JOY!

Anyway, it quickly became apparent that they didn't truly understand their estate and they were looking at everything as a single system. As a build manager this set all kinds of alarm bells ringing - I hope they're not expecting me to build this huge system everytime there's a change to one small section...

Release day is worse!! Their current approach is to collate all of the changes for each of the subsystems and deploy them in one go and call it release X. Really?? Think about that in terms of Microsoft Office - I've made changes to Word and Excel, but not PowerPoint and then said we have version 2 of MS Office. We're then losing valuable information about the structure of Office; Word V2, Excel V2 and PowerPoint V1. I know its a crude example, but I hope you see my problem.

The Solution

Well, the first thing is going to be define solid boundaries in the system. Whilst this sounds quite straight forward, there's heavy dependancies on one of the systems in particular. Think of it as a viewer on a central database that is fed information from the other systems. Most often when a change is made, this 1 system will need an update too.

Implement a build framework. Currently, individual files are copied to a staging area then copied into the environments manually - this is not acceptable.

Tools - Command Prompt Here

"Command Prompt Here" is a handy tool for Windows Explorer to open a command a prompt directly from a desired folder in filesystem. It avoids opening a new command prompt window and then traverse to your desired location.

The below are the steps to configure. Please note its not an installable, just configurable.

Hope this helps you in your day to day tasks.

In explorer, open Tools, Folder Options.

• Select the File Types tab.
• For Windows XP: Go to NONE / Folder.
• Select the entry labeled Folder
• For Windows 2000/XP: Press Advanced button.
• Select New
• In the action block type "Command Prompt" without the quotes.
• In the app block type "cmd.exe" without the quotes.
• Save and exit Folder Options.

How-to - Checklists

In one of my earlier blogs I mentioned the importance of writing down all the steps you perform as you progress through testing a new piece of software. I just found an old BEA Weblogic document, and at the end of it there was a checklist. I was so taken back by this simple type of document I had to write about it.

I was having a conversation with one of the contractors this morning and we were discussing the amount of bumff official documents have - you can write off the first 6 pages to indexes and official crap about target audience etc.

If the document is an instructional type then we may want to read all the additional info the first time, but we wont need it when we want to use it just for reference. In fact, this could hinder productivity. Instead, make it standard practice to include a checklist in the appendices outlining the instructions given in the document.

To make a checklist:

• Only have 3 columns - Requirement, Notes and a Completed checkbox.
• Requirements are triggers. Requirements should provide enough information to get the synapses in your brain firing and retrieving the memory of the additional information in the document.
• Notes provide additional info. This can be links to external resources or other parts of the document. Include gotchas here.
• Completed. As each task or step is actioned you can tick it off the list.

I'm sure you're reading this thinking "are you serious?", but as simple as this is, it's often the simple things that get forgotten about. The great thing about a checklist is, if you have followed the information I gave about making notes; this will take little extra effort to complete.

Here's a great example of how they can be used effectively: Weblogic- Deployment Checklists

Developers - DONT DO THIS!!

Just dont do it! Ever!!

Continuous Integration - the devs checklist

As I work through the book Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (Addison-Wesley Signature) I find myself highlighting sections that I feel are extremely useful and important. I dont claim to know everything, I've only been in this field for 2 years and only worked for 1 company. My experience is limited but this book has proven to be a valuable resource - there are bits i disagree with and I will go through those as I progress through the book.

Here's a section the author discusses. When a developer is ready to submit a piece of work:

1. Before submitting any changes a developer should check to see if a build is currently in the "Successful" status. If not, a developer should assist in fixing a build before submitting new code.
2. If the status is currently "Successful", a developer should rebase his/her personal workspace to this configuration.
3. Build and test locally to ensure update doesn't break developers functionality.
4. If Successful, check in new code.
5. Allow CI to complete with new changes.
6. If build fails, stop and fix on developers machine. Return to step 3.
7. If build passes, continue to next work item.

Build & Release - Rules for Managing development tools

I've just started reading Software Build Systems: Principles and Experience by Peter Smith PhD and one of the chapters discusses development tools and how to best manage them. This is only a small part of the book, but it's one of my favourites because it's easy to implement and the benefits are huge.


#1 Take Notes
I think this is one of the most important things to do when testing tools or running a proof of concept. It's so easy to get carried away with simply getting something to work that you actually forget the steps you took to get there. I would recommend getting yourself a little notepad and jotting down some bullet points - this can be fleshed out later. I personally like to open a text editor like notepad and put everything in there. Mainly because its easier to copy and paste file paths than jott them down on paper.

#2 Use Version Control for Source Control
This rule relates to tools you use that need to be compiled for different targets. You shouldn't always trust that your files will be available online (if thats your source). By keeping your tools in version control you can always rest assured that if anything catastrophic ever happens to your source, or even if they just remove them, you will always have them.

#3 Periodically Upgrage Tools
I'm going to aproach this rule quite differently to the book. I think there has to be a happy medium here; you need to upgrade your tools regularly to stay inside support, but also do it in a controlled manner and not as soon as a new release is made available.

A short time ago I was caught out upgrading one of the plugins on our continuous integration tool. To cut a long story short the latest version of one plugin was faulty and braught down our whole CI system. At the time I done a big bang upgrade of the plugins the CI used and it was a nightmare to track down the root cause and rectify. The moral of this is time the upgrades well, give new releases time for error's to manifest, but upgrade so you get new features and bugfixes.

#4 Version Binaries
I think this should be an extension of rule #2 because the reasons are pretty much the same. Just to reiterate though, keep the tools you use versioned and in your repository so that they are always available!

Weblogic/WLST - Packing and Unpacking a Domain

When you start working with distributed domains there will come a time when you need to pack the domain and unpack it in its distributed areas.

Whether you create your domain via the GUI or by scripting, all you're actually doing is creating a series of configuration files. At this point you're not actually starting any servers - that comes later.

Lets consider the following architecture:

AdminServer = Machine A
Managed01   = Machine B
Managed02   = Machine C
Cluster01      = Managed01, Managed02


So, you run through the wizard and configured the domain above. You should now notice your domain has been created on Machine A, but if you log into Machine B or C nothing exists. This is where the need to Pack and UnPack comes in.

To pack the domain run the following WLST script:



This script opens the domain and extracts (as a jar) the configurations required for the servers that will reside on Machines B and C. It's a skeleton configuration because the Admin server information will be excluded - a domain only ever has 1 Admin server.

Now that we have a templateName.jar we can send it to the machines that the rest of the domain will reside on and run the unpack script on each machine:




Replace the dummy properties with the ones you want for your domain and the script will do the rest. Do this for each machine then you're done. Ensure you have a Nodemanager configured on each machine then start the admin server and administer the domain as per usual.