Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 4: Bloated Tooling

For the last several years I have been using tools like TeamCity for doing most of the CI/CD at the places I've worked. TeamCity was a revolution for me, coming from CruiseControl and I've been a very enthusiastic JetBrains fan for many years. My closet counts some 13-15 jet brains t-shirts (R#, TeamCity) :).

I used to love TeamCity. It could do everything. Yes everything!

Man, I could:

• build software
• run scripts
• send emails
• provision servers
• create databases / infrastructure
• deploy binaries all over the place
• just about everything could be automated...

Wait a minute that’s bad, very bad.

Nothing should do everything!

That's making a mess of the domains, treating them as if they were one.
Would you like to have just one application running all of you 100+ business apps, in sort of a "complete integration pattern"? 

No way! That's an anti pattern.

As I emphasised in my previous posts the build server should control one domain only, the build domain.
This domain has 3 major responsibilities/subdomains:

• Build the software
• Run the tests / verify the quality of the software
• Package the software

Nothing more.
It certainly should NOT deploy your software and most definitely NOT run trivial tasks such a creating databases for testing, function as a scheduler for repetitive tasks or as an notification hub for the entire company.

In this same manner your deployment technology of choice, should also have one conceptual responsibility: Deploying packages.

But for some reason most of the tools I’ve seen are all Swiss Army Knife inspired tools. They have been designed to perform way, way, way too many different and complex tasks.

This is the number one mistake i’ve done and the number one mistake i see people do over and over again. Put everything into the build/deploy tool!
However its hard to blame people as tools like TeamCity are bloated with cool features, which allows, if not inspires to abuse. 
They are over engineered and as if that was not enough, there are 100's of post on the net with people showing off just how much they can bend/exploit the tools, not realising that they are hurting themselves.

Developer's tends not to question the many capabilities of a tool, instead it's often a selling point:

See here boss, if we buy TeamCity we also have the option to use it as a task scheduler for doing trivial ops tasks + we could write some scripts and let it deploy our software. Ohh and with this custom plugin we can also use it as minor ticket system which we could bend a little for our own local work processes...

By now I hope that you can agree upon or at least be open to the following statement:

Building and Deploying software are 2 completely different things that has next to nothing to do with each other, besides the package contract.

And contemplate this for a moment:

• It should not be hard to build software
• It should not be hard to deploy software (thank you Microsoft…)

Gold plated tools are by far one the biggest downfalls we have pushed upon ourself as a community.
No single tool can or should handle all the requirements across all companies, countries, transcending law, etc. At least not until we are one united planet, with one conscious master mind...

But we always seem to seek that perfect fit, which promises to solve all our problems and when we get into trouble with the chosen path, we tend to bend the rules we have, instead of contemplating the domains:

• Should this be refactored?
• Are we crossing a domain boundary?
• Is this actually a new domain?
• Is this the right tool?
• Do we even need a tool?

Bloated tooling is bad, avoid it. Building and deploying software should not be hard. 

For example configuring a build should not take more than a couple of minutes and it should not create a hard binding to a tool.

TeamCity/CruiseControl .Net are good examples of tools which offer to many capabilities, binds you to their platform and are way to complex to configure. On the side they also force you to do a ton of manual maintenance (build agents, visual studio, new versions, etc) that will keep you from developing new business software, as it is very time consuming and most likely will get you more and more frustrated over time.

If you claim that you need these kind of tools because you are developing highly complex software. Then my answer will be: Then there is something wrong with your software or the way you are developing the software. Keep it simple.

You end up with a guy named Jack, if you are not extremely careful.

On the other hand, if your name is Jack, you might have a job guaranteed. That is until the day a guy like me gets hired and starts asking questions :).

Next: Part 5: A real life example of simple it should be