CI – Start Small and Scale It Later

When you hear the words Continuous Integration (CI), you immediately think about this big project with Jenkins, long builds, failing tests, and a budget sinkhole.

Is this preventing you from getting started?

I’ve witnessed it before – Companies delay building a CI process because it’s perceived as this big undertaking that will consume time and human resources and make everyone miserable.

But Continuous Integration is not about the tools and the system, but having a development process that makes your team more productive:

• Ensure that your code is stable when working with a growing team – WHO BROKE MASTER AGAIN?
• Create a predictable product – You know what you’ve built. No more rogue deployments from the developer’s machine.
• Some observability to the development process.
• Just like my kids (and me!), developers need some structure and a routine to follow, or else tantrums ensue.
• This is especially true if you are working with containers and striving for immutable artifacts. You want to build once, knowing damn sure what went into that image.

So how can we frame CI so it doesn't seem like a massive project to undertake?

Let’s break down a simple workflow that you can implement which has value and shouldn’t take too long to implement.

On our shopping list:

1. It begins it when developers make changes to the codebase.
2. We want to be able to build our code.
3. Run some static tests to make sure it looks pretty.
4. Our developers worked hard and wrote Unit Tests (ahem), so let’s use them.
5. Bundle and version our code so we can deploy it later.

Are we missing a few things? Yes, sure, and I can think of many other items, but it’s much better than having nothing.

How would a simple CI pipeline look like for a team that has no process in place?

1. Kick in when you push code to the main branch. Later, you can run more things on Pull Requests, but let’s leave it for now.
2. Run a few static analysis tools like eslint and prettier.
3. Build the code.
4. Run Unit Tests
5. Bundle up the build results and save them for later. This could be a Docker image or just uploading a Jar.

That’s it.

With all the fancy tools available out there, and most likely that they already available with your Git platform, you can get started very quickly.

For a team that builds the code on developer machines and deploys them directly to production, this is a great advancement towards a more structured process.

It will save you some hassle with merging broken code, inconsistencies in deployed versions, and my all-time favorite – oops, I forgot to add that to git (and it worked when I deployed the app directly from my computer).

Still afraid to get started?

Get in touch