Bitbucket Pipelines – Adapting for WordPress

At Wibble, we would see ourselves as one of the best web design and best web development studios in the UK and Ireland. This reputation has been hard-earned, by constantly pushing ourselves to improve our amazing web design and web development offering. We are constantly changing and improving our services, technology and processes. In our strive to cement ourselves as the best web design studio in Belfast and Ireland, we have turned our attention to improving our deployment process. For this we looked to Bitbucket Pipelines.

As part of our web design and web development process, we use a range of tools to automate and manage code deployment for the websites we design and develop. For the past few years, we’ve used a service called DeployHQ, which has been important as the business has grown with more developers joining us as we grow steadily. DeployHQ automates the deployment process and allows developers to focus on the code and not managing the files that need to be uploaded to the server. The benefit of that is that it prevents issues when multiple devs are working on the same project, it removes the danger of someone overwriting some else’s changes. Everything goes through Bitbucket, which is a GIT code management service, and then DeployHQ detects those changes and sends them to the right place on our fully managed WordPress servers.

Bitbucket handles the storage of the theme files for a given website, and it provides a single place to plan projects, collaborate on code, test, and deploy. The “deploy” part of the BitBucket offering is something that was added while we were already using DeployHQ as part of our web design and development process. Until now, we hadn’t considered using it. The deploy feature of Bitbucket is called Pipelines, and it offers a similar feature set as DeployHQ, but it’s slightly more “developer” focused, with the config for deployment stored in a YML file. 

After collaboration within our web development team, we decided recently that we would try out the Pipelines feature to see if we could use that going forward, as a web deployment alternative to DeployHQ. There are many compelling reasons for switching, but the main one is that it’s part of the Bitbucket package, and keeping everything together in one service just makes more sense.

I was tasked with figuring out how to set up a deployment with Pipelines. Setting this up wasn’t as difficult as I thought it might be. There was some learning involved, as I haven’t had to work with many YAML files in the past. The indents can be a little frustrating at times when you’re getting to grips with it.

I’ve included a config I’ve used, and I’ll quickly go over what’s happening and how to set up Pipelines for a repo. This should form a good starting point for any other web design studios wanting to improve their understanding of the web deployment process that we are introducing.

Developer related stuff

With the config, you create different “steps” for different tasks. With DeployHQ, we can have steps that build and optimise the CSS and JS of a theme. This is something that needed replicated with Pipelines, but it was fairly simple to do.

    - step: &npm
        name: "Generate frontend assets"
        image: node:12
        caches:
          - node
        script:
          - cd public/content/themes/{$THEME_NAME}
          - npm ci
          - npm run build
        artifacts:
          - packages/**

Another step that was required was the actual deployment of the files. For this, I started by using atlassian/sftp-deploy. This worked fine for deployments, but I quickly ran into an issue. The deployments on DeployHQ would realise if a file had changed, and only deploy the updated files. Whereas using the SFTP script, it was deploying everything each time. This was slowing down the build times, as it would need to transfer more files each time and increase the chances that a user may experience a sub par experience when browsing one of our custom web design projects. Therefore, I looked into other options and found rsync-deploy, which seems to suit much better.

- step: &deploy
        name: Deploy files changes
        deployment: production
        script:
          - pipe: atlassian/rsync-deploy:0.6.0
            variables:
              USER: $SMTP_USERNAME
              SERVER: $SMTP_SERVER
              REMOTE_PATH: '/home/master/applications/{$APP_NAME}/public_html'
              LOCAL_PATH: $BITBUCKET_CLONE_DIR

The last part is the branches area, where you can choose what branch should do what. This is very useful, as you can choose to run different steps for different branches, like on develop or master branches. For now, I just have this set up to run the “npm” step, followed by the “deploy” step. By default, it won’t run the “deploy” step which is OK for now. What I could do here instead is set up the pipeline to deploy to a staging site by default, and then if it’s a push to the master branch, we can handle that as well by pushing the master changes to the production server.

pipelines:
  branches:
    default:
      - step: *npm
    master:
      - step: *npm
      - step: *deploy

Here is the full script.

definitions:
  caches:
    node: public/content/themes/{$THEME_NAME}/node_modules
  steps:
    - step: &npm
        name: "Generate frontend assets"
        image: node:12
        caches:
          - node
        script:
          - cd public/content/themes/{$THEME_NAME}
          - npm ci
          - npm run build
        artifacts:
          - packages/**
    - step: &deploy
        name: Deploy files changes
        deployment: production
        script:
          - pipe: atlassian/rsync-deploy:0.6.0
            variables:
              USER: $SMTP_USERNAME
              SERVER: $SMTP_SERVER
              REMOTE_PATH: '/home/master/applications/{$APP_NAME}/public_html'
              LOCAL_PATH: $BITBUCKET_CLONE_DIR

pipelines:
  branches:
    default:
      - step: *npm
    master:
      - step: *npm
      - step: *deploy

You’ll see some variables in here, which look like “$SMTP_USERNAME”. These can be added to the repo settings under Deployments.

We’ve decided to document this process even though it is still, very much, a work-in-progress, so more testing will be required before we fully bring it into our web design and web development processes. I’ll try to update this post, or add some more posts in future to follow up on what I find.

Conclusion

This desire to constantly improve our web design and web development processes is a reflection on the amazing team of web designers and web developers that we have here in our Belfast web design studio. This investigation into BitBucket Pipelines did not come from senior management with a desire to reduce costs, it came from the team of developers who thought they can learn a new skill and improve the process that Wibble uses to deploy sites to servers. This desire to constantly improve and push our offering is what makes Wibble stand out as a leading web design and development studio, in our opinion.