Adding A CI/CD process to my work flow is one of the really quick wins I do on every serious project I work on.

Whilst most of my personal work is hosted on Gitlab, a recent project I was working had its code in Bitbucket. This was my first time working with Bitbucket, so I wanted to document how I built assets, linted and ran tests using its pipelines.

What will these pipelines do?

By the end of this article you should have a working bitbucket-pipelines.yml file for your Laravel project which will do the following:

• Use composer to install your projects dependencies
• Run php-cs-fixer to enforce a code style
• Run larastan to run static analysis against the code base
• Run php-cs-fixer and larastan in parallel
• Run phpunit to run our projects test suite
• For a production build yarn run production
• Allow us to manually trigger a deployment to production using Laravel Deployer.

At our company setting up gitlab ci configuration is one of the jobs I end up doing by default.

This weekend I wrote a package to help speed that process up by generating a .gitlab-ci.yml file as well as installing some of the packages and configuration files to make the following possible:

• Setting an edbizarro docker image based on your target php version
• Handle Javascript asset compilation using NPM or Yarn
• Lint Javascript and Vue files with Eslint
• Lint php files using the laravel shift rules for PHP-Code-Fixer
• Perform static analysis with Larastan
• Run phpunit tests

The package currently provides a single artisan command to do all of the above after answering a few simple questions.

Check the repo out here:

https://github.com/talvbansal/laravel-gitlab-ci-config-generator

Recently I wrote about my current Gitlab CI process, when it came to the deployment part of the process I showed how I was handling it using a tool called Laravel deployer but I didn’t breakdown what laravel deployer was doing and how I had it configured.

The Laravel deployer docs are pretty good however I found a couple of server config issues that I always find myself referring back to when setting up auto deployment. Mostly to automatically restart Laravel Horizon and restarting Php-fpm without needing sudo privileges.

Lets imagine I was going to a set up Gitlab CI / CD for a fictional project hosted over on the fictional domain of deployer.talvbansal.com with a real repository here that is hosted on somewhere like Linode, Digital Ocean or even AWS.

Introduction

My most read articles on this blog are about Gitlab CI/CD with PHP. They cover a basic linting, testing and crude deploying process.

Today I want to look at my current CI/CD process for my Laravel projects in more depth. Currently the pipelines of my projects might vary slightly but is very similar to this:

So there are 5 main stages in the process:

• Preparation - The pulling down of dependencies and storing them in an artifact
• Syntax - Check code syntax
• Testing - Run unit tests
• Building - Build assets
• Deployment - Deploying to an appropriate server

The stages are processed in order with each stage containing one or many tasks. Should one task fails in a stage then the whole pipeline stops and is marked as failed.

To run the pipelines I make use of gitlabs free tier which gives you access to 2000 shared minutes per month as well as a runner on a server I have. More about setting that up can be found here.

Introduction

Laravel apps read sensitive information from their .env file.

Recently I found out that Laravel Mix can pass values from the same .env file to the js portion of your app as long as they are prefixed with MIX_

I use Gitlab ci pipelines to build production assets so that I dont need that additional tooling on the production servers the main one being:

• yarn run production

This is preceded with cp .env.example .env meaning when the build commands are being run, they are going to use values from the .example.env file.

If your project doesn’t make use of anything from the .env file then this is totally fine, however in scenarios where you do, since production applications will almost certainly have different .env values to those in the .example.env file (Never commit credentials to source control!) the resulting file will have been built with the wrong credentials.

In this article I’m going to show how you can use gitlab CI to build those assets with updated environmental variables so that they function as expected when deployed to your production servers.

Last year I began working at a new startup - NX Technology.

As a start up with limited funding we’re constantly looking for efficiencies and ways to get the most out of what we already have whether that be in hardware or software.

Whilst previously I’ve set up and self hosted a gitlab instance at NX we needed to get things up and running asap so we decided to use the gitlabs free tier.

At the time of writing the bronze tier comes with unlimited private repositories and 2000 gitlab ci minutes using gitlab’s shared runners.

One of the things I love about this is that once those minutes are up you can either pay for more or use your own runners to process jobs for your projects.

We have an old -nothing special- server which we’ve set up a gitlab runner on that will handle jobs for us along with gitlab’s shared runners and when our free minutes run out all jobs will run through that server.

Since most of the time when you’re pushing code to gitlab your laptop will be on, you can use your development laptop to help out too!

When doing any sort of development work I’ve always preferred working on an Ubuntu machine.
Doing so has helped me understand the servers that our production code has always been run on.

Towards the end of last year I started work on a new project that made heavy use of Spatie’s Event Projector package.
Without getting into the package too much, at its core it stores the payloads of all recorded events in a JSON column within a stored_events table.

I hadn’t needed to use JSON columns before and since they were a part of MySQL 5.7 which was released in 2015 I had assumed there’d be no issues with using them.

For the most part I was right, writing unit tests with Laravel’s build in tools has made me come to love writing tests and made TDD part of my daily workflow.
However when I tried to run the same tests within Gitlabs CI/CD pipelines I saw the following:

1
2
3
4
5
6
7

PHPUnit 7.5.6 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.2.15
Configuration: /builds/secret-project/phpunit.xml

 ==> Tests\Unit\ExampleTest ✓ 
"{"errors":["SQLSTATE[HY000]: General error: 1 no such function: json_extract (SQL: select * from \"stored_events\" where \"event_class\" in (App\\Events\\ClaimReported, App\\Events\\ClaimUpdatedByApp, App\\Events\\ClaimCreated, App\\Events\\ClaimUpdated, App\\Events\\ClaimUploadCompleted) and \"id\" < 1 and json_extract(\"event_properties\", '$.\"claimUuid\"') = 0dab4335-c5e8-3564-9a0a-d0537cd697f4 order by \"id\" desc limit 1)"]}"

Introduction

Recently at work we started using PHP7.2 for all of our new projects. We’d previously been using the TetraWeb docker images for our Gitlab CI needs, however they only (at the time of writing) have a docker images for versions up to PHP7.1.

I tasked one of the junior members of my team with upgrading one of our projects and came back to our repositories commit history looking like this:

Kind of ugly and not so useful when scanning our commit history.

In this article I want to show how we can test our Gitlab CI config locally whilst we’re working out how to set it up properly before we push it to Gitlab as well as keep our commit history cleaner in the process.

Introduction

My latest projects at work have evolved from being PHP / Laravel applications with sprinklings of Vue JS on the front end to being almost entirely Vue JS components driving the frontend with Laravel backends.

Whilst laravel ships with Laravel-Mix to make webpack / asset compilation easier it doesn’t ship with anyway to lint your javascript.

Luckily adding eslint and defining rules for your .js and .vue files to follow is pretty straight forward.

Update March 2020 - I’ve given written a newer more updated version of this article, check it out over here.

Introduction

This article follows directly on from my previous article on adding gitlab’s CI to my PHP projects.

Once we’re happy with our code being automatically tested we might want it to be automatically deployed to a testing server / environment or maybe even production.
Continue reading