Config CircleCI deploy Heroku

Tram Ho

Original article: DnlBlog

The day before, I learned about CircleCI. By the way, this personal blog made me wonder, why not use CircleCI to deploy to Heroku? Although deploying an application to Heroku is not too difficult and takes a long time, all we need to do is pull the new code and push it back up to the Heroku branch master. But if we can use it for free, why do we refuse, moreover, using CircleCI also makes us have more to deceive the unknown brothers (a bit sad that we have not been able to trick anyone, other brothers more awake than me).

What is CircleCI?

First we need to know what CircleCI is. Simply put, it is a platform that allows us to test code, and deploy code automatically. Imagine, you have a website and to run that website you need 69 servers. Every time you release a version, what things do you have to do? Certainly not at all. But with CircleCI, you do almost nothing, just press the merge button on Github, BitBucket … that’s it. CircleCI will help you do everything from pulling the latest code, checking if the current code is causing an error, accessing each server and deploying your code on it. can help you much more. But first you have to tell it what it will do first and where you will communicate with CircleCI is .circleci/config.yml .

Configuring CircleCI

Usually a CircleCI config file will include 3 main components:

version : Specifies the version to be used, each version will have different keywords.

jobs : Defines the scripts to be used at runtime.

workflows: The order and conditions for running the above scripts.

Now I will go into detail on each part to step by step build up a CircleCI config file.


version: 2.1 We use the latest version of CircleCI is 2.1. That’s all in this section.


In this section, we will define 2 jobs to serve our purpose, CI / CD, in which the steps to implement CI will define it in the build section.

Stay in the docker, we use two images is circleci/ruby:2.6.3-stretch-node and circleci/mysql:5.7 along with setting some environment variables to be used in the container corresponding to the this image.

We define the steps we need to do inside the steps section. Those steps include installing bundle:2.1.4 and the necessary gems. These gems after installation will be cached based on the content in Gemfile.lock . This means that only when Gemfile.lock changes, will bundle again and then the vendor/bundle will be updated. This will greatly reduce your build time. Next we run the command:

This command waits for circleci/mysql:5.7 until it is initialized and ready to connect. Inside the Rails app, we configure the config file config/database.yml with the following content:

Then use the command:

to be able to use these environment variables in the Rails app. Before that, don’t forget to add:

Come on into Gemfile. At this point we have completed the build of our application using the docker provided by CircleCI. Next you can run whatever you want, in your case:

If there are no errors, then your build is considered successful, and you have just completed the CI for your application. From here we can see, implementing CI for an application, the most important thing is not how you did it but whether your application was written tests or not. An application without test is the same with CI or not.

Now that we come to the CD, what we want CircleCI to do will be defined in the deploy section.

In this part, everything looks simpler. We don’t need to use docker, all we need is a computer that can pull the code on the master branch, log into Heroku and then push that code to Heroku. CircleCI can provide us with such a computer:

Simply like that, you have what you want. You can see this as an intermediary server that is responsible for connecting your Github and Heroku. By default, when registering for CircleCI, your connection to Github is completely handled by CircleCI, so with the command:

You can now pull the latest code from your Github. So now just need to find a way to connect to Heroku again.

First you should check out .netrc here . .netrc simply .netrc is a file stored in the home directory on Unix operating systems, it allows the user to save the user name and password, then use it to log into the FTP servers automatically. It’s simple to get here, we just need to write Heroku credentials into ~/.netrc on the server that CircleCI has just provided:

In which you pay attention to 2 variables $HEROKU_USERNAME and $HEROKU_PASSWORD , these are the environment variables you must set on CircleCI. In the Pipelines, each project will have a Project Settings section, from here you can easily find Environment Variables section, this is where you add the environment variables needed for their application. You can use these variables anywhere in .cricleci/config.yml by .cricleci/config.yml the variable name $ .

Done somewhere, you may have to give the server permission to read the ~/.netrc file when it ~/.netrc to log into Heroku:

If everything goes well here, now will be the most important moment. We will add Heroku remote to the local repository (here is the server we are working on):

Next, push the code to the Heroku remote branch master that we just added:

And finally, run some other necessary commands:


Recently, we have identified what to do in the CI / CD process. Now it’s time to determine their order of execution:

We define a workflows named build_deploy . In this will perform 2 jobs that is build and deploy corresponding to the 2 jobs that we just built above.

Its content can be understood simply as: ” Perform build when there is any change on Github, if there is a change on the branch master, after successful build, deploy new code “.


Here, to summarize all the things just done, we will have a complete .circleci/config.yml file:

Good luck!

Share the news now

Source : Viblo