Configuring Continous Delivery Inside Private Gitlab Instance Using Heroku
Usually, setting up a CD pipeline using Heroku is as simple as creating an app on Heroku and linking it to our Github repository. Okay, but what if you’re not using Github… Well, it’s a little bit more complicated.
First of all, this tutorial depends significantly on the CI/CD services you’re using. I’m using Gitlab Pipelines, but the main ideas can be implemented using other providers. I’m going to assume that you are only interested in deploying the app, and we’re not going over the CI and testing steps.
Today, we’re going to deploy our app to two Heroku apps, one for the main / production branch and the other for the staging branch. We can also create a reviews app using these steps, but it’s a little bit more complicated; we’re going to touch on this in the end.
First, we must create the apps on Heroku and write down the application name. Then we need to go to your account dashboard and grab the API key.
Now, let’s start configuring our CI/CD system. Go to your respective CI/CD system and add the application names and your API keys to the environment variables of the pipeline. If you’re using GitLab pipeline, you can go to your repository settings > CI/CD > Variables.
After we’re finished inputting the required variable, we can tell the pipelines what to do with it. I have attached a basic example of a GitLab pipeline definition file that I will explain.
First, we need to tell the runner what steps/stages are in our pipeline. As we’re only going to deploy the app, we’re only going to need the deploy stage.
Then we define the task that runs in the stage. Using the “ rules “ directive, we can limit the task to only run when certain conditions are met using the “rules” directive. In this instance, I am limiting the “Deployment” task to only be run in the “main” branch and the “DeploymentStaging” task to only be run in the staging branch.
We also need to tell the pipeline runner what image/platform the runner will run our task. Since we’re going to use Dpl gem to deploy our app, which needs ruby to run, we should use the ruby image.
Next, we specify what actions need to be done in the task. It can be split into a “before_script” and “script”. The “before_script” is run before the “script”. In this stage, we can install the required dependencies, set up some variables, etc. For our instance, we need to install the aforementioned Dpl gem and install the Heroku CLI.
Now, we’re ready to deploy our app. In the “script” directive, we can tell the Dpl gem to use Heroku to deploy our app using our Heroku API key and app name. After that, we can do any setup that the application needs. As I’m running a Django-based application, I need to run the migration script in case the database schema change. You can also run other things here, such as collect and offload your static file to an external storage service, etc.
Finally, we should tell the pipeline where our app deployment can be found. We do this by using the environment directive and putting the deployment URL and name.
That’s all the steps needed to deploy your app to Heroku from any git provider using a CI/CD pipeline runner. You can extend this script to deploy even more branches or create automatic review app creations.
If you’re going to automate the review app creation, the basic step is to create an app using the Heroku CLI on the “script” directive. Then run the deployment using the newly created app name. It would be best if you created the app name using a combination of your project name, the branch name, and maybe the commit hash to ensure that the resulting app name is unique. It would be best to have an “on_destroy” handle to automatically destroy the created app so that it won’t hog up your account limit.