May 7, 2019

Continuous Deployment with JHipster and GitLab

So, you want to get started with Continuous Deployment. Maybe you’re creating a new project, and you want to implement a modern approach to the SDLC. Or perhaps you want to simplify and accelerate the deployment process of an existing application. Or you’re on a team that utilizes CD already, and you want to better understand how it works.

Whatever brought you here, welcome! In this guide, you’ll create a Spring Boot + React web application, deploy it to Heroku, and build a CD pipeline that will run tests and prepare the app for release at the click of a button. Sound like a lot? Don’t worry! The tools we’ll be using are super simple to set up, and this guide will walk you through the process.

Tools and Prep

If you don’t already have a GitLab account, go ahead and sign up for one. It offers free private repos and CI/CD services, as well as a rich set of project management tools. We’ll be using their product to build, test, and deploy our app.
We’ll be deploying the app to Heroku, so you’ll want to create an account there as well.
JHipster is a neat framework that enables you to build a web application in seconds. Just type a few commands, and JHipster will generate a modern front-end, with Angular or React, and a Spring Boot server-side application. It includes a suite of unit tests, as well as generators that will make it really easy to build the CD pipeline. We’ll install the JHipster CLI later in the guide.
Make sure you’ve got the basics installed: Java, Node.js + npmGit CLI.


Step 1: Create a GitLab Project

Head to and create a new project. Call it whatever you want, and don’t worry about initializing with a README, JHipster will take care of that.

Now go ahead and clone that repo in the command prompt:

git clone [your repo url]
cd [your repo slug]


Step 2: Build the app with JHipster

OK, let’s install JHipster and run it:

npm install -g generator-jhipster

Follow the prompts to create the app. You can mostly use the defaults, except for:

? Would you like to use Maven or Gradle for building the backend? Gradle
? Which *Framework* would you like to use for the client? React

When JHipster finishes, you’ll have a fully functioning web app, complete with front-end and back-end tests, user authentication, and application metrics!
Next, lets create an entity:

jhipster entity Team

Follow the prompts to create a couple fields. When it creates the files, use “a” to overwrite all.
When the process completes, run:


Once the app is running, go to localhost:8080. You should see your brand new web app! Log in, create some Teams, and look around at what JHipster has built out.

Step 3: Deploy to Heroku

Let’s deploy this thing! Install the Heroku CLI from here. Once it’s installed, run:

heroku login -i

Provide your Heroku credentials to authenticate.
Next, we’ll use the JHipster Heroku sub-generator to prepare the app for Heroku and deploy it:

jhipster heroku

Use the default configuration, except for:

? Which type of deployment do you want ? JAR (compile locally)

When it finishes, try heading to the url provided by Heroku. Your app should now be running live! Go and add a couple Teams in the live database.

Step 4: CD, Finally

Well it took a few steps to get here, but now we’re ready to build our CD pipeline. JHipster has another sub-generator that will help create the GitLab configuration:

jhipster ci-cd

Choose GitLab CI, Yes to the Docker container, and select Deploy to *Heroku*. Take a look at the new .gitlab-ci.yml file it created. It instructs GitLab to compile your app, run front-end and back-end tests, and package the app for release. Notice the “when: manual” config on the deploy stage. This means GitLab won’t deploy to Heroku automatically, instead waiting for manual approval. If you would prefer to deploy automatically you can remove that line.
I do recommend adding the following under deploy-to-production:

        - master

This will ensure the deploy step is only run from the master branch.

Before we go any further, we have to add the Heroku API key as an environment variable in GitLab. Go to your Heroku Account Settings and copy the API key there. Then go to your project on GitLab and select Settings -> CI / CD from the sidebar. Under Environment Variables, add a new entry with the key “HEROKU_API_KEY” and paste the api key in the value. Now we’re ready to commit our changes and trigger the pipeline!

git add .
git commit -m "Add CD pipeline"
git push

Once the changes are pushed, go to the GitLab project again and select CI / CD -> Pipelines from the sidebar. You should see your brand new pipeline running! If everything goes well, it should compile your app, then simultaneously run front-end and back-end tests in separate containers. Finally, it will package the app. When these jobs complete, you should see a play button next to the deploy-to-production job. When you’re ready to deploy, just click the button and it will trigger the deploy to Heroku. If you removed the “when: manual” line in the gitlab configuration above, the deploy step should have been triggered automatically.

Step 5: Reap the Benefits

Now that we’ve got the pipeline in place, you can start to enjoy the benefits of CD. To demonstrate, let’s say we want to add a new entity to the app. First we’ll checkout a new branch:

git checkout -b player-entity

Now we’ll use the JHipster CLI to create the new entity:

jhipster entity Player

Add a few fields, and this time, add a new many-to-one relationship to the Team entity. When it finishes, commit and push:

git add .
git commit -m "Add Player entity"
git push --set-upstream origin player-entity

Now we can create a merge request for this new branch. Notice that the url for creating a merge request is right in the output from the git push command. Follow that link and create the request. You can also go to the Pipelines page and see that the pipeline is running, this time without the deploy step.

As a reviewer, notice that on the page for the merge request, you can set it to merge automatically if the pipeline succeeds. This will trigger a new pipeline on master, which will include the deploy step. Once you deploy, you should see the new Player entity in your live app!


Hopefully this guide has been helpful for getting started with CD. To learn what else you can do with GitLab CI/CD, visit their docs. If you have any feedback, let me know in the comments below!

About the Author

Paul Norton profile.

Paul Norton


I am a software engineer with several years of experience in Java web application development and reactive front-end technologies. I’ve led teams and built applications from the ground up, and I enjoy working with stakeholders to intuit problems and create innovative solutions. I try to improve myself daily through continuous learning.

One thought on “Continuous Deployment with JHipster and GitLab

  1. Stephen says:

    Followed the tutorial to a tee but Heroku complains, “No web processes running”.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Android Development for iOS Developers
Android development has greatly improved since the early days. Maybe you tried it out when Android development was done in Eclipse, emulators were slow and buggy, and Java was the required language. Things have changed […]
Add a custom object to your Liquibase diff
Adding a custom object to your liquibase diff is a pretty simple two step process. Create an implementation of DatabaseObject Create an implementation of SnapshotGenerator In my case I wanted to add tracking of Stored […]
Keeping Secrets Out of Terraform State
There are many instances where you will want to create resources via Terraform with secrets that you just don’t want anyone to see. These could be IAM credentials, certificates, RDS DB credentials, etc. One problem […]
Validating Terraform Plans using Open Policy Agent
When developing infrastructure as code using terraform, it can be difficult to test and validate changes without executing the code against a real environment. The feedback loop between writing a line of code and understanding […]