Na, na, na, na, na, na, na, na, 
    Na, na, na, na, na, na, na, na, 
    Na, na, na, na, na, na, na, na, 
    Batman!

We've all heard it. Some of us even grew up when it was first aired on TV. Be honest, who among us, hasn't experienced just a little bump in cardiac rate when the Batmobile fired up?

It's pretty much a given that when The Batman gets involved, bad things will usually be made better.

Usually.

S. K. was a developer at Gotham-Dev, Inc. They were doing work for an event-management client located in Gotham City in the U.S. The client had an in-house programmer who called himself The Batman because he had a propensity to swoop down upon and make all sorts of problems better.

One day, The Batman decided that all developers should create an entire branch for each and every bug/feature/issue, no matter how small it was. This way, each change could be coded in and of itself, and without interference from changes made for other issues. He proposed this up the chain, and received the corporate blessing to impose this new policy as law.

As a contractor, S.K.'s team of 12 developers had to comply, and so started creating separate branches for every little work task. After an entire week of this, there were 50+ new branches, and counting. While this may seem excessive to some, it didn't matter to the developers as their changes could be made in isolation. It was the responsibility of The Batman to merge those 50+ branches and deploy the whole thing on the test environment. After several hours of merge-hell, The Batman sent the following email:

   From:    The Batman <[email protected]>
   Date:    Fri, Jun 13, 2014 at 12:02 PM
   Subject: Bam! Process improvement!
   To:      Dev-Team <[email protected]>

   To cut down on confusion and working space issues, I've created a new space and 
   protocol on our devops server just for QA operations. For instance, this week's 
   Dashboard release lives at:

       http://qa.eventmgmt.com/dashboard/release/2014-06-13 

   Individual branches will be installed for testing, like so:

       http://qa.eventmgmt.com/dashboard/branch/BUG-2134

   The only time when it's acceptable to edit code in a QA instance is when you 
   are making last-minute, pre-release changes. When this is necessary, please 
   only do so with QA's knowledge and understanding.

   Please let me know if you have any questions/comments/concerns.
   
   -The Batman-

Ok, so The Batman has to restructure the QA and bug branch directory layout. While daunting, it didn't really affect the developers, and in fact, it only really affected QA. A short time later, The Batman sent another email:

   From:    The Batman <[email protected]>
   Date:    Fri, Jun 13, 2014 at 4:18 PM
   Subject: Thwap! Process improvement!
   To:      Dev-Team <[email protected]>

   I will be moving public site release candidates to the same system as soon as 
   possible. Currently the public codebase makes some hard assumptions about URL
   and path structure which requires the site be installed to /home/username/dir 
   - deeper URL structures cause problems. Once these auto-config issues are solved 
   we'll have all our releases under this process - in the interim I will continue 
   pushing front-end releases to dev-w.

   Please let me know if you have any questions/comments/concerns.
   
   -The Batman-

Again, this also seemed harmless as a few minor code changes were required to eliminate the old assumptions about the old path structure and replace them with new assumptions about the new path structure. The developers were not worried. Shortly thereafter, The Batman swooped in with yet another email:

   From:    The Batman <[email protected]>
   Date:    Fri, Jun 13, 2014 at 10:47 PM
   Subject: Sok! Process improvement!
   To:      Dev-Team <[email protected]>

   Regarding databases for these installs: we've had problems in the past where 
   using the test database allowed a branch to go live with database scripts 
   which did not work. In many cases the database scripts specifically named the 
   test database, so in an effort to prevent these "gotchas" I am currently using 
   an entire database for each release.

   On the upside, this means up-to-date test data in the release candidates.

   
   -The Batman-

Ok, so then there were countless database instances to go with countless branches in both development and QA.

But the development staff need not fear all of these issues because The Batman was here!

I think The Joker might have viewed The Batman's actions as impinging upon his domain!

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