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

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

Im not trying to bad mouth what a lot of people out there are doing, I'm trying to wake them up.
Rattle their cage.

There are alternatives to overly complex CI/CD setups and I would like to share a ground breaking experience I had when I recently demo'ed the first part of my new take on CI/CD for my colleagues.

I have used TeamCity for years. Never once, NOT EVEN ONCE, have a fellow developer asked me a question that contains even a fraction of the following statement:

Wow, that TeamCity stuff looks easy. Can you give me a 5 minute tour or a link so I can get up and running with this great new idea I have?

But guess what, when I did the demo of our new setup with a cloud build service, 1 guy actually disrupted the demo to ask me the following question:

Wow, that looks easy and cool. Can you give me a login so I can get started right away?

A week later another developer asked the same question (more or less). Now i get more time to do actual business development.

The beauty of the cloud service we are using is that it enables us to setup a build in 20 lines of simple, readable text, which is stored besides our solution file in raw text. This almost makes us independent of the cloud service as we have the build configuration under version control.

This story says it all.
Configuring a build should be this simple and in the future it will get even simpler, just take a look at some of the PaaS's out there. But with current, old technologies, such as locally maintained build servers, you are stuck with a guy called Jack and developers who won't get involved very often. Things will break and hurt more.

The real and absurd truth hidden in this little story is that finally the build domain appears to be simple enough that the domain experts themselves understands it. This is NOT the case with tools like TeamCity.

Imagine if that happened with your business apps...

Next: Part 6: How to avoid the pitfall