I love to build things.

Software, training courses, woodworking, or emails, it doesn’t matter. Building things is absolutely wonderful.

You know what’s not wonderful? Having to build the same thing over and over again. It ruins the experience, because you’re no longer creating and pouring your heart and soul into it. You’re just burning time on make-work.

It’s no different with software.

CI/CD⌗

Continuous Integration and Continuous Deployment (CI/CD) is a pair of closely-related principles that have gotten intense traction over the past decade, and for good reason.

The core idea is that you should always be building, testing, and releasing your product. You want to reduce your time-to-market, shortening the feedback loop for updates, and remove the fear and risk that comes with longer release cycles.

Why do you care? You’re just writing code, yeah?

Not so fast.

Your World Without Automation⌗

When you need to release a new version of your app, what do you do?

  • Bundle up all the code files into an archive
  • Try to remember what DB changes were made since the last release
  • Upload the files
  • Realize you forgot the static files
  • Rebundle everything with the static files this time
  • Update the database
  • Update the code
  • Restart your server
  • Email your customers letting them know the app has been updated
  • Remember that you forgot to update the cache-busting configuration value, and go do that

Sound familiar?

You honestly need a checklist for the entire process, just to make sure you don’t forget anything. But running through the same steps on-command is exactly what we invented computers for!

Yes, setting up automation for your workflow requires some up-front effort. So does everything worthwhile.

Manually deploying things is time-consuming, breaks your development flow, eats into your already-limited supply of energy, and is simply risky.

You’re spending more energy doing it all manually than you would setting up CI/CD.

Benefits⌗

In addition to saving time, energy, and risk, CI/CD can offer additional benefits:

Testing⌗

Making sure tests get run for every code commit is difficult.

Sometimes you simply forget. And the less said about that one developer (“But the compiler will catch any errors!”) who never runs tests and insists on YOLO builds, the better.

If your CI/CD server always does it, you can be sure it’s getting done regardless of whether somebody wants to be difficult or not.

Multi-Target Builds⌗

If your app runs on multiple platforms, CI/CD can do all the packaging work in-parallel for you.

  • RPMs
  • DEBs
  • Zipfiles
  • Tarballs
  • Container images (one for each distro base image)
  • AWS AMIs (one for each region you support)

And so on. Even just doing all of that locally on a dev machine can take a long while, and ties up resources that could otherwise be used for Quake Deathmatches watching the latest episode of Alone implementing that awesome new feature.

Consistent Builds⌗

You want your builds to be consistent.

Your code relies on every piece to be exactly where expected. Your hosting platform relies on configurations to be in the proper place. Your users and documentation expect that your instructions are accurate.

If you’re doing your builds by hand, things will get overlooked, and your reputation will suffer as a result.

Consistent Deployments⌗

Nothing is worse than deploying your code and forgetting to update that one server. If CI/CD is handling your deployments, you can be sure that it’ll get the job done right, every time.

New Dev Startup Time⌗

How many times have you started on a new-to-you project and promptly spent the next 3 days trying to get everything sorted out and working to build the project locally?

How often do you suffer from, “New computer, need to setup my build environment again…”?

CI/CD bypasses that entirely. The build server handles all the heavy lifting, and so you and everyone on your team can focus on implementation. Have editor, can build.

Tools⌗

CI/CD is such a big deal that there are a ridiculous amount of tools out there. Some are free, some are paid. Here’s a quick list of ones you should evaluate:

Free, Open Source Solutions⌗

  • Jenkins: The 800lb gorilla of the CI/CD world. One of the oldest job runner platforms out there, it’s still heavily used by orgs large and small.
  • Gitlab CI/CD: The community edition of Gitlab includes a fully-functional CI/CD system for projects hosted on your Gitlab instance. This is a no-brainer for folks already using Gitlab for their source control system.
  • Concourse: An up-and-coming automation platform, it’s built from the ground up to be provisioned and configured via code.
  • CDS: CI/CD with a focus on enterprise-grade features, flexibility, and self-service. Supported by Europe’s leading cloud provider, OVHcloud.

If none of those appeal, there are plenty more to choose from.

  • Github Actions: Chances are you’re already using Github for your source control. If so, Github Actions is an easy option to integrate with. They even give you ~60 minutes per day of free builds.
  • CircleCI: An excellent platform with great Github integration. Their free plan includes just under 200 minutes per day of no-cost builds.
  • AWS CodePipeline: The AWS service for CI/CD. I’ve never used it, but if you’ve got money to burn and want to keep everything on AWS, this is your tool.
  • Azure Pipelines: The Azure equivalent of AWS CodePipeline. Same service, different font.

No Free Lunches⌗

The biggest thing to remember is that you pay for the time to do your builds, one way or another.

  • If that’s building on a developer machine, you’re paying for the machine and wasted dev time.
  • If you’re self-hosting a CI/CD server, you’re paying for that server and the maintenance time.
  • If you’re using a paid service, your monthly bill will remind you quite thoroughly.

If you can take advantage of the free tiers of the paid services, good on you.

Realistically, they’re there as gateways to get you integrated with that system and willing to pay to keep things running when you burn through your allotment of free build time.

There’s nothing wrong with that, but it’s something to go into with your eyes open.

Recommendations⌗

  • If you’re super budget conscious, use Github Actions to dip your feet in and explore the idea of CI/CD. You get ~60m per day of runtime for free. That’s plenty, and you’re probably using Github already. Swap out for CircleCI if Github makes you antsy.
  • If you don’t have any other prevailing concerns, spin up a Jenkins cluster. That will give you the biggest bang for your buck, and VPS costs are pretty low. You can set it up to automatically spin up on-demand runners when you have build jobs queued up, so you’re not even spending money on runners when you’re not actually building things.

Action Steps⌗

Here’s your next steps for benefitting from CI/CD in your workflows:

  • Implement separate scripts to build, test, and deploy your app. This will make CI/CD extremely easy to integrate with, will help you avoid vendor lock-in if you decide you hate the platform you chose, and will let you still do things manually if your CI/CD server has an outage. Been there, done that, it wasn’t fun. Seriously, encapsulate these bits in one-liner scripts for simplicity. You’ll thank me later.
  • If you’re using Github for your repo, set up Github Actions to build-test-deploy your app to a QA environment when you make a PR to your main branch. If you’re using Gitlab, do the same thing but replace “Github Actions” with “Gitlab CI/CD”.

Next up: Immutable Infrastructure, or “Speed up your runtime in X easy steps!”