CI/CD = CI/CD^2 = CI/CD/CD???

Exactly what is CI/CD? Sure many know what the short version stands for and even then it can be a little confusing. For instance maybe you get Continuous Integration. It allows small and/or quick changes to be committed and integrated into your main branch . There is some confidence in the integrity of your code; because it should be constantly going through unit and integration testing. It is also able to build consistently. What about CD however? Possibly you have heard two different definitions. However they can sound very similar if not the same just from the naming alone. So is it Continuous Delivery or Continuous Deployment? Well it's both and while its often used interchangeably they are different. In tech many things are kept short and/or abstract. So while everyone uses the short version to keep it concise, I like to think about it really as CI/CD/CD or CI/CD^2. Translation Continuous Integration, Continuous Delivery, Continuous Deployment.

Continuous Delivery

Continuous Delivery builds on CI. CI gives a nice automated process which produces a sanity build of your software. Now you need a nice auto delivery of the product. Let us refer to Continuous Delivery as CD for this part. With a small team its easy to imagine various states going on all at once. Someone can be checking in code while another has some test going on etc etc. We need a way to see the updates and possibly how it works in a central live environment. For many this is called the staging environment. The staging environment is usually where anyone on the team can test and review before we deploy to production for all to see. However we don't want someone constantly waiting to act on this; nor do we want everyone's hands in the pot do we? Instead we want a predictable routine. This includes some defined rules which can be viewed by anyone such as a schedule for instance. Using reproducible steps which run the same on each iteration. We want this process to be predictable resulting in an expected quality product each time. Managing environment, services, etc, should also be included in CD. By having this automated delivery process we can have a happier and more productive team. Just how work is constantly being produced and changes are happing at any moment. The pipeline is set to constantly keep churning out new versions of the product.

Continuous Deployment

Many stop at Continuous Delivery and with good reason. Not everyone is ready or even desires Continuous Deployment. Where as Continuous Integration and Delivery were about how the organization can benefit and improve workflow productivity. Deployment now involves the users. Continuous Deployment is the next step up and is about deploying to your production environment. With no one to interfere the product quickly goes from being in house to now being live for all users. As you can imagine their is a huge reliance on automation for all this to happen. Therefore due diligence needs to be done by reviewing the entire pipeline. To each their own but some may not want or can't implement this due to standards and regulations. Others may not have the automation in place for infrastructure or rollbacks in case something fails. One can name a ton of possibilities as to why or why not to implement. Whatever the reason Continuous Deployment rewards should be weighed heavily along with the risks.

Why CircleCI?

I have dealt with my share of CI/CD tools but for this post CircleCI will be the focal point. It's the one I have become accustomed with the most lately. While I am sure down the line I will experiment with another tool again I must admit I really like it. It has a ton of features I like but something I really appreciate is just how easy it is to get started with a new project. In this post I'll walk through how to get up and running locally as well as with the cloud platform.

Why a local setup? There are a few benefits but speed and convenience are big ones. Having some minimal quick access to debug files and config changes, without having to commit and push each time were reason enough to pique my interest. The time investment to set up locally is also very little in the grand scheme of things; So why not get the most out of it? Of course you will need to sign up for a CircleCI account (circleci.com) which is free to start building. It can also instantly be used with a Github or bitbucket account.

Install CircleCI with HomeBrew

There are several ways to install CircleCI locally but I did it through good old trusty homebrew. Because I had Docker for Mac already installed. It's actually recommended that you use the following command.

brew install --ignore-dependencies circleci

If you don't have Docker for Mac install just do

brew install circleci

Now lets validate that you indeed have it installed and that everything is working as expected.

You are going to want to obtain your Personal API token. Once signed into your CircleCI account, navigate to User Settings → Personal API Token and generate a new one, if you don't have one already. Make sure to copy it somewhere, since you won't be able to see it again. If lost you will need to regenerate a new token.

Personal API Tokens.

With the newly acquired Personal API Token you can now configure circleci. Run the command below and it will start a quick walkthrough. If you are not setting this up on a dev server or in the cloud yourself, the default circleci website supplied is your host.

circleci setup

Validate that your local setup works. In a project root directory create .circleci/config.yml. For validation purposes just copy & paste the barebones setup below which you will want to change later to suit your purposes.

version: 2.1
jobs:
  build:
    docker:
      - image: circleci/node:12.16.1 # the primary container, where your job's commands are run
    steps:
      - checkout # check out the code in the project directory
      - run: echo "hello world" # run the `echo` command

Running the validate command in the root of your project directory should find the config file and return a statement that the file is valid.

circleci config validate
Config file at .circleci/config.yml is valid.

Conclusion

You now have a working CI pipeline locally. However thats not the only thing you accomplished. Remember earlier I stated I liked how easy CircleCI makes it to get up and running? While this post guided you through a local setup. You already have what you need to start using the cloud hosted platform as well. With your Github or Bitbucket account you used to sign up for CircleCI. Once you push the branch up to your repository with the changes you made in ".circleci/config.yml". Your cloud account will also do its thing and run the pipeline. Pretty much you are already up and running. Go ahead and give it go. Moving forward as the code gets updated, you should also make the proper changes to update the config.yml as needed. This is just the start and will be a series of post. As we progress, we will walk through some of those changes together. Please feel free and let me know any thoughts, comments, questions. Till next time!