Why create another automation system?

First of all, I don’t think all other systems have some fatal flaws that cause them to be terrible. They are good at what they do and fill the needs of the people that use them pretty well. Many of the hosted solutions are excellent and cover many of the uses that most developers have.

So why create another one? The primary reason is because I wanted to create one for myself to better understand how they work. Seems counter-intuitive, but I usually do things the hard way.

Ok, well there must have been other reasons?

My current employer Kaiser Permanente has an interesting environment for mobile apps as we have some in the public app stores, and many internal apps hosted by an internal app store. Also we have policies in place that prevent the usage of most publicly hosted solutions. For many years we have run Jenkins servers and recently have built a comprehensive pipeline for our mobile app teams to use.

Overall, however, there are limitations in how Jenkins operates. While powerful in its use of plugins, this also moves control out of the hands of our build engineers and they are at the mercy of how the plugins work. We wanted a system that gave our build engineers complete control and provide a great user experience to developers.

The foundational principles

Having identified that we wanted a new system, we came up with some foundational principles that we built the system with: