Continuous delivery for WordPress using Bitbucket Pipelines

I look after a team of developers who all follow the practice of continuous delivery. I thought it was about time I applied the same principles to my own site but I wanted to do it for free.

Continuous delivery aims to automate the testing and release process so you can deploy new code with a click of a button.

The problem

My current setup uses Atlassian’s Sourcetree (which is free). It helps simplify how I interact with my Git repository. If you don’t know what Git is you can read the Git basics here.

My repository (repo) is then backed up in the cloud using Atlassian’s Bitbucket which is also free for small teams. So far, so good.

Now here comes the problem. To deploy code I would have to manually move files via SFTP (a secure version of FTP) from my local version of the site, to staging and finally to production. This process was slow, prone to errors and had no version control.

Goals

I wanted:

all main branch commits to automatically update my staging website

all deployments to be versioned

the ability to roll back to a previous version

to manually trigger a deploy to production with one click.

Pipeline setup

To achieve these goals I used Bitbucket Pipelines, another Atlassian product which will automatically deploy and test a website.

For my setup I decided to use Pipelines to only update my WordPress Theme and to upload files via SFTP but you could use FTP.

For this setup you need to be using Bitbucket and to enable Pipelines.

To enable Pipelines go to your repository settings and then select Pipelines settings.

Toggle the switch to enable Pipelines. Before you configure your bitbucket-pipelines.yml file you need to set up some environment variables which I’ll explain next.

Environment variables

To setup your environment variables go to:

‘Settings’ (within your Bitbucket repository)

Selecting Pipelines ‘Environment variables’.

I created two variables:

SFTP_password

SFTP_username

The variables are the username and password required to access my site via SFTP. If you don’t know the password and username just ask your web host.

The variables have to be all one word but you can call them anything you want.

.yml file

Bitbucket Pipelines runs your builds in Docker containers. These containers run a Docker image that defines the build environment. You can use the default image provided by Bitbucket or get a custom one.

To create your Docker container you need to create a bitbucket-pipelines.yml file. Go to your repositories settings and then your Pipeline settings and click the button ‘Configure bitbucket-pipelines.yml’. I selected the language as PHP and replaced the template with the following.

Once you have a successful pipeline build change ‘init’ to ‘push’ and then commit the pipeline again.

Now you’ve set up your pipeline every time you commit and push code to your Bitbucket repository, your staging site will automatically update, however your production will require you to manually trigger the deploy.

To manually trigger your deploy on production:

go to your Bitbucket repository

Select ‘Branches’

On the master branch line click the three little dots ‘…’

Select ‘Run pipeline for a branch’

Once selected you will get the custom pipeline we created called ‘deployment-to-prod’. Click ‘Run’ to start the deployment.

You should now have a fully functioning pipeline with proper versioning allowing you to rollback any change.

Conclusion

Having Bitbucket Pipelines is great, even for this simple example. I can now easily deploy code from local, staging and to production with very little effort, and at the same time everything is version controlled.

The only downside is you only get 50 free minutes a month to deploy your code.

Each deploy lasted around 30 – 60 seconds which means I could do around 30 commits a month. I think for most hobby sites this is probably fine.

Next I’m going to see if I can introduce some testing with each commit such as unit tests or some automated tests with Selenium.

Comments

Kylesays:

3 February, 2018 at 10:47 pm

This post assumes little knowledge of web development workflow and clearly explains advanced terms and processes for novice/hobbits devs. Thanks for dummy-friendly instructions!

Hi Putnik, the quick answer is I don’t know. For wp updates and plugin updates you could use the process I’ve described above. For DB changes I’ve always used plugins to help migrate – but this is just a hobby site.

Peter Woodwardsays:

31 January, 2019 at 6:32 pm

The article mentions the limit on the build minutes. It should be noted that more build minutes are available for as little as $10 a month.

I’ve been using this method for about 3 years for various clients and it’s a huge time saver!