In 2019 I wrote about how I get around static IP restrictions when working in different places.
The world is very different now and whilst I’m not travelling anymore I still use sshuttle regularly to make my traffic look like its coming from a given location.

Recently I started switching some of my projects to run on docker locally (annoyingly this was before Laravel Sail was announced). However one of the challenges with sshuttle + docker in the way I’d originally got things set up is your networking gets messed up and consequently nothing really works for the project - not ideal.

Thats not the end of the story though, there’s an easy fix here - exclude the docker subnets from sshuttle.

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 and Prerequisites

I’ve been remote working full time for over 3 years now.

In that time I’ve had to work with a number of clients who restrict access to their internal systems via IP Address whitelisting.

As a developer who often works from different locations and countries this can quickly become problematic.

A paid for solution is to purchase a Dedicated Static IP VPN from a reputable provider like NordVPN. and ask the clients IT team to whitelist your new Dedicated Static IP.

This is something I’ve been doing for a while and whilst the initial set up is a little fiddly, (You have to set up 2 accounts and get their team to link them together) its worked flawlessly for me.

However if you have the following:

• SSH access to a device in a location with a Static IP (Perhaps you get one from your ISP or your office has one)
• You use Linux or OSX (Sorry windows guys I don’t think even with WSL this will work).

Then you can use the super handy command line tool SSHUTTLE to route all (or some) of your traffic through that device.

Lets take a look at getting it working…

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!

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.

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

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

Introduction

Gitlab provides some good documentation on getting build runners for your projects set up which can be found here. However I haven’t found a good article on setting up Gitlab CI for PHP applications yet.

This article is not going to discuss setting up shared runners on Gitlab since I felt the documentation provided by them in the link above was easy enough to follow, what this I am going to focus on is the .gitlab-ci.yml configuration that I’m currently using in my projects to do the following:

• Run PHP CS against our code base to ensure that it conforms to PSR-2
• Run PHPUnit against our code base to ensure that our unit tests pass against different versions of PHP (5.6, 7.0, 7.1)