Connecting GitLab, Codeship and Laravel Forge

Modern web development requires tons of things to care. After we implemented our new feature and wrote the tests, we want to push it to a version control system (VCS).

Then we want to test the code in different environments. But it’s hard to setup on our local machine, so we decide we use a Continuous Integration Platform (CI)for that. Of course, we want to trigger our tests automatically in the CI, so we need to connect with our VCS.

After the tests passed, we want to deploy the new code to the server. Again, we want to automatize this process, because waiting for the tests and deploy the code manually can be boring and annoying. So we need to setup our CI, when our tests ended to let the server know, it can clone the new code and deploy it.

Of course that would be so nice to see all the notifications at one place. That means we cannot miss a project management tool either, what is connected with the VCS, the CI and the server as well.

Sophisticated enough? Yes, it is…so let’s see the steps. We are going to use GitLab as the VCS, Codeship as the CI and Laravel Forge for the server management.

Working with GitLab

GitLab is an awesome free git based VCS. What I like in GitLab is they provide private repositories for free. Of course, in most of the things all the primary version control systems (Github, Bitbucket, GitLab) provide the same, it’s up to you what you choose.

We don’t want to cover the basics now. Let’s assume we have a repository already what we want to connect with a CI. GitLab provides a built-in platform for that, but now we want to connect our repository with Codeship to test our code automatically on every commit we make.

We can setup the connection on the Codeship part, so let’s move on!

Connecting our repository with Codeship

Fortunately, Codeship makes the things easy and painless. After registration, we can create a new project. We need to complete three steps to finish the process.

“Connect Your SCM”:
Here you can choose what git service do you want to use. You can choose Bitbucket, Github, and GitLab. Of course, now we want GitLab.

“Choose Your Repository”:
As a second step, we need to provide the repository. For example: https://gitlab.com/pinecode/test.

“Configure Project”:
Finally, we need to configure our project. We can choose which plan do we want to use for this project. After that, we can setup our commands / scripts. Also, there are predefined setup commands what we can select as well. For now, we choose the Laravel [PHP] option. Note that, since Laravel 5.5 requires PHP 7.0, you need to edit the version from 5.6 to 7.0 or higher.

Also, we need to update our environment variables at the environment tab. We just copy-pasted our local environment (APP_ENV=local), but we set the database connection to SQLite (DB_CONNECTION=sqlite) and the database to in memory database, with the special :memory: value (DB_DATABASE=:memory:).

After we are ready with the configuration, we can commit to our repository, and the tests will run automatically. From now we can see a little indicator at the repository’s page about the latest test.

Next to the commit ID, we can see a green check icon. That’s the indicator of the last test. In this case it passed.

Now we can see our CI and the VCS we use are connected. The tests run automatically after our commit, in the environment we setup for it. Let’s move on and connect our repository with Laravel Forge.

Setting up Laravel Forge with a GitLab repository

Forge is an excellent tool, to manage servers. If you are not familiar with that, you should checkout the features.

First of all, we need to link our Forge profile with the VCS we want to the user. In this case, we need GitLab. Fortunately, Forge is using OAuth, so we don’t need to create the SSH keys manually.

After the connection finished successfully, we can add our repository to the server we have. It’s never been easier, all we need to do is to give the correct details at the “Git Remote” section.

We select GitLab as a provider and give the repository’s path.

After this, we connected our VCS with the Forge server, less than 3 minutes. But we are not done yet! Don’t forget, we don’t want to push to the server directly after a commit, we want to trigger our tests — which is working now — and we want our CI to trigger the deployment after the tests passed. So we need to take care about two things:

1. Make sure, the “Quick Deploy” switch is off.
2. At Codehip’s surface we need to setup a deployment pipeline.

Let’s see how can we setup the pipeline: First of all, we need to navigate to Codeship and go to the “Project settings” and “Deploy” tab. Here we need to give the branch, in this case, we use the master branch.

We can configure the branch what triggers the deployment pipeline.

After we saved the branch, we have several options what do we want to add to our pipeline. In our case, we scroll down and select “Custom Script”.

Now the question is, what do we want to do here? We want to trigger our deployment here, but how? Fortunately, Forge provides an excellent solution for this. At Forge, we can find a ”Deployment Trigger URL” section. All we have to do is to copy this URL and make a POST or GET request pointing to this URL from our CI.

Note that, I changed the site ID, the server ID and the token as well.

After we copied the URL, we can paste it to the “Custom Script” at Codeship’s surface.

Note that, we add wget before URL to make the GET request. Without that it would not work.

After we saved the script, not only the deploy pipeline but the whole workflow is ready.

+1: Setup notifications with Slack

Slack is an excellent tool — I guess, I don’t have to introduce it — where we can manage our projects way easier than before.

In our case what we want:

1. After a commit trigger a 1st notification
2. After the tests finished trigger a 2nd notification
3. After Forge pulled the code trigger a 3rd notification

Why is that so useful:

1. We see the whole progress and the results at one place
2. We get notified and we don’t have to check them manually
3. If something goes wrong, we have a picture where the things broke

Fortunately, we can connect all the services with Slack. For Forge and Codeship we have an easy job, few clicks and the configuration is ready. For GitLab we need to use WebHooks to trigger Slack notifications. Here is a link for the docs: https://docs.gitlab.com/ee/user/project/integrations/slack.html

Our workflow so far

We have a repository, where we implement some new feature, or we found a bug we want to fix. We edit the code and commit it to GitLab.

After we pushed the current code, Codeship automatically runs the tests on the freshly updated repository. After the tests passed, Codeship makes a GET request on the URL what we copied from Forge.

The request triggers the deploy process, so Forge pulls the changes from the repository, and we made sure our app has a valid code.

If we set the connection with Slack before, we get notifications from all the services we use. We can easily track the errors down if we have some.

So this is a comfortable, secure and automatized way to deploy code.