Continuous Integration Tools — What makes it so difficult?
Recently, I was reading this report about how tools for Continuous Integration, need to be better. For years, I have been doing Continuous Integration. For years, I have listened to people touting the greatness of tools. Tools that would make our lives better. If I believed half of what was promised, I would expect that the world should be overrun by robots by now.
Tooling in Continuous Integration, has evolved over time. How did hey start? Well let’s consider a few quotes to figure that out.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. — Martin Fowler (https://martinfowler.com/articles/continuousIntegration.html)
Build Tools — Do it our way!
When Continuous Integration was first brought on the scene, it needed tools to automatically build and test software. That software was meant to automate the mundane and keep people in the know of what was happening. Overtime, those tools have been Frankenstein-ed into a Continuous Delivery tool or something worse.
What has always fascinated me was what is required from these general tools. The accepted norm is to take an already existent process and shimmy it into some new tool. They always ask that you translate what ever you do, into something they are doing. If your processes doesn’t match, well, then you need to conform. You need to do it our way!
Stop the Insanity!
There is a better way. I founded a principle that drives everything I do with Continuous Integration/Delivery, something that makes all the difference in the world, I am calling it Continuous Confidence.
Everything we do, we should do in terms of confidence of the release. We have processes that are unique to each project we do. There maybe some standard parts, but there are unique things we do to gain confidence in the builds we are producing. There might be, build processes, unit testing, functional testing, integration testing, smoke testing, and many more. There is always something unique. So what do we do?
What makes you confident?
So what makes you confident. Start there. Do you have some scripts or commands that you use to always build or put things together? Write them down and consolidate and order of things. Do you trust your build and test tool? If everything is good to go, can you release immediately? If the answer is fraught with trepidation and uneasiness, what is causing that? Ask yourself what more can I do to gain confidence about the changes I made?
All of this needs to be considered. If you think about, the rudimentary logic we use with releasing software comes directly from the question:
How confident am I that I didn’t break something?
So, find a tool that gives you confidence. Overtime, you will find something that helps you grow your confidence. I am a huge proponent to just do what you need to, don’t make something a Frankenstein just because you can. Use the right tool for the Job. So, within a DevOps world, we need to find something that can build and test, and something that can track a release.
Rapid-Framework
Over the years I wanted something new. I wanted a CI solution that treated CI like infrastructure. I feel it should be simple, and out of site out of mind. It should be layered and very tiny. So I wrote Rapid.
Too often I found tools that were bulky and overly complex. Servers that need 15GB of RAM just to run the master nodes. Clients that bled memory into 500MB processes. That was too much.
Rapid was developed with scale and simplicity in mind. The master takes 48MB of RAM and the client 24MB of RAM. Nothing more. It is written in python and quite scalable. I have run upwards of 180+ clients on this structure with no negative impact.
So how do you start? Take a look at: https://www.github.com/Bamboohr/rapid. There are some configuration pieces still needing documentation, but the start is there.
Continuous Integration — In Pursuit of Confidence
So, what am I getting at, besides a shameless plug? Confidence. Grow the confidence you release process. Does something not feel right? It probably isn’t. Trust those feelings. Trust the people you work with, from other orgs besides just Development. Listen, and confidence will pop up everywhere. Allow your process to use the tools the way you need. Don’t let the tool define your process. Build day upon day until your confidence is where it needs to be.
