GitLab self-managed now available on Release

I’m happy to announce that we now support customers using self-managed versions of GitLab Enterprise and Community Editions. Like with the SaaS offering, you can now integrate Release and deploy environments against repositories that live in your self hosted GitLab service.

Release is a platform that enables you to deploy all your environments and applications. As part of your development cycle, you can use Release to test branches before they hit production using our ephemeral environments. With instant Datasets, it helps your team ship with confidence by testing changes with production-like data.

We will go over the GitLab setup steps today. We will:

1. create an application on GitLab,
2. configure your Release account to talk to GitLab, 
3. connect your Release account to GitLab
4. use ephemeral environment to test your code with Release

 If you have any questions about Release or any new features we are working on, feel free to drop us a line.  

Create an application on GitLab

For Release to authenticate with your hosted solution, you need to configure an application on GitLab’s side to whitelist Release.

In the user’s settings, there’s a section called “Application”. If you access that section, you will be presented with a screen to create a new application. This application needs to have the proper settings defined so Release can access your GitLab repository. In essence, you’ll need to make sure two things are set up properly: the callback URL and the scopes.

The scopes is a set of permissions that will be granted to Release on your behalf. For the integration to work properly, you need to set the scope to “API”.

The callback URL is the URL that GitLab is authorized to send requests back to. If you’ve ever worked with OAuth, this will be familiar to you.

Here’s how the application should look like in GitLab:

Once your application is saved, you will see additional information that will be needed on the Release side. Keep that tab open until you have successfully connected Release to GitLab.

Here’s how it should look like in your GitLab account:

Configure your Release account to talk to GitLab

You can now configure Release to talk to GitLab. Go to your user profile to see all the current integrations we support. We want to use GitLab self-hosted. 

Click on Configure to open up a dialog that allows you to enter the credentials you created in GitLab earlier.

Fill in your GitLab URL, ClientID and Client secret and Save. Note that pressing Save will only store the information and won’t validate what you have entered. Validation will occur once you attempt to connect to GitLab. The “connect” button will appear once you save your information. 

Connect your Release account to GitLab

Clicking on that Connect button will open a new tab and direct you to GitLab. If your information checks out, you will be redirected to your GitLab self-hosted service.

The first time Release will attempt to connect to GitLab, you will see a dialog that will ask if you want to authorize Release to connect to your application. Once you authorize the connection, GitLab will redirect you back to Release. At this point, GitLab and Release are connected.

Use ephemeral environment to test your code with Release

Now that you are connected and ready to go, you can use Release to deploy ephemeral environments connected to any working branches in GitLab.

For every app you configure, the Pull Requests your team does will automatically deploy to Release as an Ephemeral environment. These unique Ephemeral environments are then available for QA and testing by everyone on your team (see docs for more details). 

This is very helpful to teams that want to validate their changes before hitting production as you can deploy an application, test features and make sure there is no regression. It’s the kind of safety net you didn’t think you needed until you started using it.