Today is a very special day for quite a few of you out there; you know who you are. For those of you not fortunate enough to work for a certain leader in the travel industry with a certain brand that is a household name, allow me to explain what Merge Day is all about. Jim M got to live through it for nearly two years.

It all started a few years ago when the company -- whom I'll call ediabitzocity59line.com -- decided to undertake the biggest technology project they had ever done: create the end-all, be-all of ecommerce websites. It was to be built from scratch and be internationalized, service-oriented, and all-around enterprisey.

Although ediabitzocity59line.com employed some of the best developers in the industry, management wanted to bring in a technology partner -- a consulting company I'll call "Big Tech" -- to help with the undertaking. I'm sure their decision had nothing to do with the fact that Big Tech's Board of Directors shared quite a few members with ediabitzocity59line.com's.

Many of the developers bemoaned Big Tech's arrival. This had less to do with the fact that Big Tech's consultants bill more per day than most developers make per week, and more to do with the fact that Big Tech is known throughout the industry for making ... errr, how do I put this nicely ... marginally functional software products with user interfaces so absurdly bad that describing them as an amalgamation of the worst of the Pop-up Potpourri would actually be a compliment. Wait, that didn't come out right. Any way, to no one's surprise, the first thing that Big Tech recommended was the implementation of an Enterprise Source Control Management Solution. And talk about convenience: Big Tech just happened to sell an Enterprise Source Control Management Solution.

The major selling point of the ESCMS was its "branching" ability. That made it an instant sell. According to the sales presentation, branching was a brand new concept that would revolutionize the way they developed software by allowing concurrent development of an unlimited amount of features. I'm sure that, had a developer had been in the meeting, he might have brought up the fact that developers have been using "branching" with source control for the past fifteen years or so.

To management, this new concept of "branching" was fantastic. They could now model their source control after their development model: three functional groups, each divided into a front- and a back-end team. The source control would be set up with one trunk, three branches of the trunk (one for each group), and two sub-branches for each branch (one for front-end, one for back-end). According to the Big Tech salesman and management, this would allow everyone to work concurrently without interfering with each other's code.

I can almost hear all of you source control experts cringing, thinking that's the exact opposite of how it should be done: everyone should work in the trunk and branches should be created at the time of incremental releases. Perhaps. But if they did it your way, then there'd be no such thing as Merge Day.

Merge Day, a departmental holiday, is celebrated on the first Wednesday of every month. On this day, the front-end and back-end team leads of each functional group would sit together and "merge" the code into their parent functional branches. After a good four to six hours of testing and merging all the conflicts that popped up over the month, the leads would then get together with leads from the other functional groups and do it all over again. Sure, it may be a long and painful day for the leads, but for everyone else, it's a fun filled day without any check-outs, submissions, or other coding-pertinent activities allowed.

Some Merge Days are even more special than others. You see, if work was scheduled to be done on a particularly complex or fragile module, development would prepare for the upcoming Merge Day with a period of fasting known as "Code Freeze". This extended the "no development" rule for everyone except the most divine of developers who were working on that module. For the regular developers, it's like a Merge Day that lasts a whole week.

Not every one enjoyed Merge Day, though. One particular developer had a very tedious and frustrating job, and could not even begin his festivities until everyone else had finished theirs. I'll call this person Ant; the reason being, there is a software tool bearing the same name that does exactly what he does. Ant's job, specifically, was:

  • wait until all the lead developers had finished merging the code
  • check it all out from the trunk
  • hand-edit the class paths whenever a new package was added
  • manually compile the WARs, JARs, and EJBs
  • manually deploy each of them via FTP to the testing environment

Jim actually prototyped and demonstrated a software package that could automate and accomplish the entire deployment process in a fraction of the time and eliminate the possibility of human error. Naturally, he was shot down by one of the lead developers; actually, the very same lead who designed the whole branching and Merge Day process in the first place. His reason: "I made a makefile once in college; they're more trouble than they're worth."

Jim is happy to report that he's since moved on and is enjoying his new position very much. His only complaint is that they won't let him take off the first Wednesday of every month in observance of Merge Day ...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!