This guide will show you how to automate your development process by introducing Continuous Delivery to your workflow using Buddy.

If you’re a developer, you probably know that the actual act of coding is only a part of the whole development process. Instead of working on code you might as well spend time trying to discern file versions, downloading and updating packages, or uploading changes to the server making your best not to mess anything up.

You can, however, reduce these ingrate activities to minimum by introducing the good practice of Continuous Integration and Delivery to your workflow. Continuous approach lets you automate repeatable activities and deliver tested iterations of software to your server literally with one click, so that you can focus on actual work.

Preparing Git repository

Making sure your files are safe and sound under version control is the very basis of CI. Let’s start from initializing a Git repository for our project. For that we shall use Buddy’s fully featured Git hosting with code editor, branch management and merge requests.

If you’re new to Git and would like to learn more, this essential guide will help you get started.

To put your project under version control you need to:

  1. Prepare your PHP project by packing into a ZIP archive. Alternatively, you can download and use our sample project from here.

  2. Create a new project in Buddy, choose Buddy as the Git provider and use the Import ZIP archive option:

    Initalizing repository in Buddy

NOTE: You can also use other hosting services with Buddy (GitHub, Bitbucket or GitLab): just choose your provider when setting up a new project. If you’re a GitHub user, you can fork our sample project from our profile and select it from the project list.

Introducing CI to your PHP project

Now that the repo is set, we need to configure a build server. Normally, this involves a couple of hours of preparations: reading documentation, server installation, downloading missing software, running, testing and optimizing the setup, etc.

However, in Buddy the build server is already installed. It uses Docker containers with pre-configured environments to run the builds. This means that:

  • You don’t have to install anything
  • Builds and tests work exactly the same for all users
  • Configuration takes a couple of clicks instead of hours
  • You can quickly adjust the process if needed

In fact, it all boils down to creating a pipeline and selecting the dedicated action for PHP.

Creating pipeline

Pipelines are series actions (builds, deployments, notifications, etc.) that visualize your workflow. They can be executed manually on click, automatically on every push to branch, or recurrently at a given time. Let’s create a pipeline that will build and test your PHP package:

  • Add a new pipeline, switch the trigger mode to On every push, and set the Wildcard to * (asterisk). This way the pipeline will be automatically triggered on every push to any branch in the repository:

    Adding a new pipeline
Configuring unit tests for PHP package

The first action will fetch and build your PHP packages so you don’t have to do it manually.

  1. Select the Docker image with pre-installed PHP from the action list:

    Choosing PHP build action
  2. Now you can set up build details and configure unit tests.

Since most of PHP projects nowadays use Composer, Buddy suggests running composer install by default. If you’re not sure how Composer works and would like to learn more, have a look here, If you don’t use Composer, just delete the Composer command.

In our case, the Composer has been configured to install the required libraries (phpcs, phpunit) and create autoloaders for tests.

Let’s add some commands that will check our code in compliance with SR2 and run all unit tests:

vendor/bin/phpcs src --standard=psr2 -spn

So that the full stack of commands will look like this:

PHP build configuration


  • You can change the version of PHP installed by clicking the Docker image → Change image and selecting tag from the list.
  • If your tests require a database to run (eg. MySQL), you can activate it in the Microservices tab in the Docker settings.
  • If you want to test your app in different instances, just add more PHP actions with a different version
Setting PHP version and microservices

Testing your build server

The pipeline is ready: go ahead and make a push to the repo. If everything was configured properly, Buddy will automatically fetch and install the required libraries and test your app:

Testing automatic release

Delivering build to location

Once the app is built and tested, we’re ready to deploy it to the server. Automating deliveries on top of builds allows you to upgrade your process to Continuous Delivery and take advantage from a series of benefits:

  • Shortening the cycle of software release
  • Clients being able to provide feedback faster
  • Reduced risk of deployment to production
  • Having one centralized build server making it easier for the QA to test the app
  • Flexible release options allowing you to quickly adjust the process to new requirements

Setting up production pipeline

Let’s create a separate pipeline for the the Master branch that will update your LIVE server with the new version of your app. Although in theory the Master branch should always be production ready (stable and bug free), we need to be 100% sure that the is code properly verified before the deployment. In practice this means configuring the same build action that we did at the beginning.

Cloning pipeline

Fortunately, Buddy lets you easily clone pipelines and actions with a couple of clicks:

  1. Add a new pipeline and click Clone existing pipeline, top-right
  2. Select the project, pipeline and actions to clone. Since there’s only pipeline in this project you can leave it at default settings. Click Clone actions to confirm.
Cloning pipeline

Changing pipeline details

Now we have to change the way the pipeline is run:

  1. Go to the pipeline details and click Change trigger mode, branch and settings in the right column
  2. Change the name to indicate this is a production pipeline, switch the mode to Manual and assign it to the Master branch. This way we’re sure the deployment can only be made on your explicit demand:
Changing pipeline details

Configuring deployment to production

Okay, the build action has been cloned alongside the Slack notification in case something goes wrong (remember you can adjust the message to your liking). Now we need to configure the deployment action:

  1. Click the plus below the build and select the transfer action for your server type. In this example we’ll choose deployment to FTP:

    Choosing FTP transfer action
  2. Provide authentication details to your server and select the pipeline filesystem as the source.

The filesystem is a clone of your repository on Buddy’s build server where the build is made. Deployment from the filesystem means that Buddy will deploy the code already processed in the build, according to your guideline.

If everything’s okay, Buddy will add the action to the pipeline:

FTP configuration

Testing the production pipeline

Since this pipeline is set to manual mode, click Run pipeline to execute it:

Choosing transfer action

The initial build and deploy might take a while (Buddy needs to install and upload all files), but later on it’s much quicker as only the changes are processed.


This guide is just an example of how Buddy can be used to optimize development processes. It all depends on the sort or projects that you run (frameworks, languages), size of your team, preferred communication practices, type of Git workflow, and other conditions important in your work. Buddy is flexible enough to assist and automate many of the above, allowing you to create separate pipelines for every environment, such as:

  • automatic builds and deployments to developer servers
  • integration tests on stage servers for pipelines in recurrent mode (eg. once a day)
  • monitoring pipelines for production servers

Once properly configured Buddy will save you and your team lots of time and resources, so you can get down to the real deal - delivering awesome software.

Appendix: Getting notified of broken builds

Only in the perfect world everything works from A to Z on every time, and development is far from exception here. The most important thing, however, is to stay aware that something bad happens. Buddy lets you use conditional actions to send notifications on failed builds, so you can take action quickly. Let’s assume every time a build fails you’d like to receive a notification to your Slack channel:

  1. Scroll down to Conditional actions and switch the tab to On Failed
  2. Select Slack notification and authorize access (you can read more on adding Slack integration here)
  3. Buddy uses parameters to specify variables in the message. Type the following contents so that you know the branch where the build has failed and who the commiter was:

     Something went wrong in	${}
     Branch: ${} 
     Commiter: ${}

    For the full list of parameters click here.

  4. Select the target channel and save changes when ready.
  5. (Optional) If you don’t use Slack, you can also notify your team with email and SMS messages.
Adding conditional action

That’s it - now you will know when a build gets broken, where it happened and whose change caused the error. And if you need any assistance in setting up your workflow with Buddy, drop a line to and describe what you want to do - we’ll be super happy to help you out!