Many people (especially developers) will have heard of continuous integration (CI) or continuous deployment (CD). However, most of them cannot explain their meanings and the differences between the two terms. So, what is continuous integration and deployment, in reality?

When it comes to going live with your application, it might seem easy to upload some files to a server and then start the application through a simple command in the shell, via SSH.

This approach might be a solution for many developers, or for small applications that are not updated often. For most scenarios, it is not a good approach, however. The word continuous represents the fact that all changes or updates are continuously reflected by our application to the user. This would be a lot of work, and it would be tough to do if we stayed with a simple file upload and took a manual approach. Automating this workflow makes it convenient to update your application at any time.

Continuous integration is the development practice where all developers commit their code to the central project repository at least once a day to bring their changes to the mainline stream of code. The integrated code will be verified by automated test cases. This will avoid problems when trying to go live at a specific time.

Continuous deployment goes further; it's based on the main principles of continuous integration. Every time the application is successfully built and tested, the changes are directly released to the customer. This is what we are going to implement.

Our automation process will be based on CircleCI. It is a third-party service offering a continuous integration and delivery platform, with a massive amount of features.

To sign up for CircleCI, visit https://circleci.com/signup/.

You will need to have a Bitbucket or GitHub account in order to sign up. This will also be the source from which the repositories of your application will be taken, for which we can begin using CI or CD.

To get your project running with CircleCI, you will need to click on the Add Projects button in the left-hand panel, or you will be redirected there because you have no projects setup yet. After signing up, you should see all of your repositories inside of CircleCI.

Select the project that you want to process with CircleCI by hitting Set up Project on the right-hand side of the project. You will then be confronted with the following screenshot:

Select the Operating System as Linux and the Language as Node. The final step will be to hit the Start building button at the bottom of the window.

The problem is that you have not configured your repository or application accordingly. You are required to create a folder called .circleci, and a file inside of it, called config.yml, which tells CircleCI what to do when a new commit is pushed to the repository.

We will create a straightforward first CircleCI configuration so that we can test that everything is working. The final configuration will be done at a later step, when we have configured Heroku.

So, create a .circleci folder in the root of our project and a config.yml file inside of this new folder. The .yml file extension stands for YAML, which is a file format for saving various configurations or data. What is important here is that all .yml files need a correct indentation. Otherwise, they will not be valid files, and cannot be understood by CircleCI.

Insert the following code into the config.yml file:

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:10
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      - run:
          command: echo "This is working"

Let's quickly go through all of the steps in the file, as follows:

1. The file starts with a version specification. We are using version 2, as this is the current version of CircleCI.
2. Then, we will have a list of jobs that get executed in parallel. As we only have one thing that we want to do, we can only see the build job that we are running. Later, we will add the whole docker build and publish the functionality here.
3. Each job receives an executor type, which needs to be machine, docker, or macos. We are using the docker type, because we can rely on many prebuilt images of CircleCI. The image is specified in a separate image property. There, I have specified node in version 10, because we need Node.js for our CI workflow.
4. Each job then receives a number of steps that are executed with every commit that is pushed to the Git repository.
5. The first step is the checkout command, which clones the current version of our repository, so that we can use it in any further steps.
6. The second setup_remote_docker command will create a remote environment, in which we can run docker commands, like docker build. We will use this later, when we are building our application automatically. The docker_layer_caching property enables the caching of each Docker command that we run. This will make our build time much faster, because we are saving each layer or command that we run through Docker. Only the Docker commands are executed, which follow a change in the Dockerfile.

7. Lastly, to test that everything has worked, we use the run step. It lets us execute a command directly in the Docker node:10 image that we have started with CircleCI. Each command that you want to execute must be prefixed with command.

The result of this config file should be that we have pulled the current master branch of our application and printed the text This is working at the end. To test the CircleCI setup, commit and push this file to your GitHub or Bitbucket repository.

CircleCI should automatically notify you that it has started a new continuous integration job for our repository. You can find the job by hitting the Jobs button in the left-hand panel of CircleCI. The newest job should be at the top of the list. Click on the job to see the details. They should look as follows:

In the preceding screenshot, each step is represented in a separate row, at the bottom of the window. You can expand each row to see the logs that printed while executing the specific command shown in the current row. The preceding screenshot shows that the job has been successful.

Now that we have configured CircleCI to process our repository on each push, we must take a look at how to host and deploy our application directly, after finishing the build.