Photo by Clark Tibbs on Unsplash
Photo by Clark Tibbs on Unsplash

My firsthand Makefile experience

June 2, 2019

Background

So to give a little background about the reason why I post this. I switched jobs about 4 months ago. Before the switch, we used the ?makefile? for basic project installation.

Makefiles are often used in Linux environments to direct how to compile a program. However, makefiles are also used to perform multiple tasks that need to be executed to achieve a certain goal, for example setting up some kind of test environment and run all the tests.

In the first few weeks at my new job, we started on a new project which needs to be set up in multiple environments. This led to trouble pretty quickly because we had no easy way to setup it up for multiple environments in quick succession.

Trial and error

In order for us to be able to set up the project in quick succession for multiple environments, we needed something that could automate this process.

Since I used a Makefile at my previous job I pitched the idea to create a Makefile that would be able to handle most of the basic stuff that we needed.

We started with a simple installation target. This would be for a development environment only at first since it was my first time setting it up by myself. Plus the fact that I seem to have trouble finding actual useful information and guides made it even more of a challenge.

Here is an example of a basic Makefile that has an installation target for a Laravel project.

Explanation

This was the first iteration of the Makefile that we used. As you can see it has four targets at this point. At this point, the default target will be the first target that doesn?t start with ?.?.

So our default goal is ?help? which prints all targets with the comments behind the target name. But you can also change the default goal by adding the following rule below the .PHONY target.

.DEFAULT_GOAL := help

The install target is a simple command that runs all the scripts that need to be run for the application to be working correctly.

This was enough for us in the beginning but we needed a way to fix our config with one line without actually knowing what artisan commands we needed to run.

Lastly, we included the test target so we didn?t need to remember what parameters phpunit needs to show the code coverage.

Usage

As time past we needed to add more things to our Makefile since it wasn?t only used for development environments but also for the testing and staging environments.

We edited our Makefile so we can pass in the environment we want to install the project for. This meant that we needed to add some extra changes to give us these options.

The Makefile is also used within bitbucket pipelines for testing, but it is also used for deploying. So all our environments are actually managed from one main file which makes it even easier to edit.

As you can see the install target has changed a little bit. We are now checking if the user ran make install environment=ENVIRONMENT_NAME.

We are checking if the user didn?t specify the environment for the install target. If the user did not add it the Makefile will default to the develop environment. If the user did specify the environment we will set the variables and add one extra check to see if the the .env file for that environment exists or not.

The scripts that are run are also changed so it will only run for the specified environments.

You may have noticed are the add-all, commit, close and push targets. The commit and push targets have a thing in common, They both execute another target before they are run themselves.

Since we want to make sure most of our code is written with the same rules we will run the _phpcs target before committing the changed files. And before we want to push our code we want to make sure all tests are passing so nothing goes to bitbucket that will break the build.

What it solved for us in short

Since we are working on a project that will be needed to be set up on multiple environments and we don?t want to lose too much time we started looking for a manageable way for us to fix it.

Because of my experience of using the Makefile at my previous job I pitched the idea to try and see if it was something we could also use.

We started small by adding an install target so we could install the project with ease in development environments, and later we changed it a bit so it would work for multiple environments.

The Makefile is not only used for setting up the project but also to integrate all our coding standards so there is little to no discussion needed in the pull requests. This meant we can focus on more important things.


That was it! I hope this article has explained how you can streamline your workflow. Please feel free to leave a comment if you have any feedback.