The continuous delivery approach aims at making the process of continuously deploying code to production error-free, or at least less error-prone, using automated tasks, tests, builds and deployments. Minimize risk and downtime, maximize quality and value. That’s the motto.
However, this process is not always straightforward, to say the least. Often enough, the continuous delivery tools chosen for implementing continuous integration and deployment are hard to figure out and use, and are usually time consuming and expensive. The bigger the application, the bigger the challenge.
This article introduces an interesting new approach to dealing with this challenge by demonstrating a continuous delivery process using continuousphp and Zend Server.
continuousphp is a PaaS solution that allows you to easily design a continuous delivery pipeline in just a few minutes. continuousphp will sync with your existing repositories on GitHub (or Bitbucket and Stash), and handle all the various stages in the continuous delivery cycle: provisioning, packaging, testing and deployment. Every new commit made to your repository will push your code down the pipeline you created (read more about continuousphp).
Zend Server is Zend’s professional PHP stack bundled with a set of advanced tools for developing, debugging, deploying and monitoring PHP web and mobile apps (read more about Zend Server).
- The procedure outlined in this tutorial uses a Zend Framework 2 skeleton application. If you want to follow the steps described below, go ahead and clone the repository.
- You’ll also need a running instance of Zend Server to complete the final step in the tutorial. An easy way for doing this is using one of the various cloud solutions – Zend Server is available on AWS, Azure, Google Cloud Platform, just take your pick. All offer free trials so it’s also a cheap way to get started.
Let’s get started!
Step 1: Setting up your repository
Before you get your hands dirty, you’re going to need to set up your repository in continuousphp.
To do this, go to https://continuousphp.com and click the Sign up for free button.
For public projects, you can use continuousphp as much as you want for free. For private projects, you get 30 free builds after which you can select any of the offered plans.
Then, you’re going to have to tell continuousphp which Git repository hosting service you want to integrate with. You can select to use GitHub or BitBucket (support for private providers like Atlassian Stash is available on demand).
Once you’ve given your credentials, the integration is set up, and continuousphp retrieves and displays a list of all your hosted repositories.
Click the Setup button on the right for the repository you want to set up a new continuous delivery pipeline for.
In this case, we’re going to be using my Zend Framework 2 skeleton application repository.
A new project page is displayed, which in the future will show the pipeline we define and any executed builds.
Click the Set up repository button, and behind the scenes continuousphp will add a new web hook to the repository for triggering new builds for each push and pull request, and create a new SSH key to allow continuousphp to clone the repository when builds are initialized. You should receive an email from GitHub notifying you of this new key.
Step 2: Creating a new deployment pipeline
Now that your repository is set up, it’s time to define a new continuous delivery deployment pipeline.
A deployment pipeline in continuousphp breaks up the deployment process of your application into parallel processes. First, your repo is cloned. Then, continuousphp provisions the application and generates, in parallel, two separate application packages – one for testing and one for deployment.
To create a new pipeline simply click the + icon as suggested by the continuousphp elephant.
Then, select the starting point of your pipeline, either at a specific branch or for all branches/tags in case of a production pipeline.
In this case, the master branch will do just fine.
Next, we’re going to specify the PHP version we want continuousphp to use for provisioning our app and executing tests. The great thing here is that you can select as many PHP versions as you like, and for every version you select continuousphp runs tests in a separate container.
Step 3: Configuring build and test settings
Once you select your PHP versions, the deployment pipeline is saved, continuousphp automatically configures any tools that exist in the repository (e.g. Composer), and build configuration settings are displayed. Your next step is to review and fine-tune these settings, and the test settings on the next pipeline page, to suit your preferences and requirements.
Build configurations allow you to define Amazon AWS credentials for integration during build execution, Phing tasks to run before creating the testing package, and Composer dependencies.
You also have the option to add HTTP authentication for allowing Composer to access private repositories (e.g. on BitBucket) or get dependencies from a private Satis server.
Once you’ve reviewed the build settings, click the Next button at the bottom of the page.
Any existing testing configuration will be automatically identified and displayed on the Test settings page, but of course you can also add a new testing framework as well.
To do this, simply click the + icon and select the testing framework you wish to add.
I’m going to add PHPUnit to my pipeline. All I have to do is enter the path to the testing configuration, in this case defined at:
Note that my testing configuration has a red Blocking tag at the top. This tag means that the Blocking feature is enabled and that any failed tests will block the package from being deployed – very useful if you don’t want error-ridden code to be deployed. Removing the tag allows the build to be deployed in warning state.
You can also define Phing targets for your testing frameworks. These are useful if you want to execute a task before testing, or for creating a database and inserting fixtures in the case of functional testing with frameworks like Behat.
Once you’re done configuring the testing setting, click Next to advance to the next step.
Step 4: Packaging and deploying your app
To complete the continuous delivery cycle, we’re now going to configure how we want the application packaged and deployed.
There are various deployment options offered by continuousphp, including using AWS CodeDeploy, but in this case we’re going to select to deploy our application on Zend Server running on AWS.
Zend Server gives PHP developers and DevOps access to Zend Server’s professional PHP stack and a set of advanced tools for developing, debugging and monitoring applications, including the new debugging toolbar – Z-Ray. The integration between continuousphp and Zend Server is based on the Zend Server SDK, a CLI application that communicates with the Zend Server web API.
The first thing we’re going to do is select the Zend Server packaging type from the available options.
Applications deployed on Zend Server are packaged into a .zpk file (compressed file) and include all the application’s files, deployment scripts, and metadata.
At this stage of the game, and without having to configure anything else, any commit will begin a continuous integration process. Which means, code is cloned from the repo and provisioning of packages for testing and deployment are initialized.
Leaving the pipeline as it is configured now leaves us with built packages that we could retrieve using the continuousphp API or SDK, but we’re going to take it one step further by defining a target for deployment.
Clicking Next, takes us to the Deployment Settings page.
Adding a new destination
We now need to add and configure a new target destination for builds. In the Destinations section , click the + icon.
Enter the URL of the Zend Server you are deploying to as well as the application’s URL (make sure the server URL includes the port number the Zend Server UI uses – 10081, or 10082 for HTTPS).
You will also need to add the name and hash of a Zend Server web API key required for authentication. This key can be created and retrieved using the Zend Server UI (Administration | Web API Keys).
Last but not least, select the ‘enable deployment for successful builds’ check-box to enable deployment.
The final step for defining Zend Server as a deployment target is adding two files to the root directory of your repository. These two files instruct Zend Server how and what to deploy and without them, deployment fails.
This descriptor file describes and defines all the necessary information needed to deploy your application using Zend Server’s deployment mechanism. It describes the application and specifies any prerequisites and parameters needed for the application to be deployed successfully.
Here’s an example of what a simple ‘deployment.xml’ file can look like:
<?xml version="1.0" encoding="utf-8"?>
<package version="1.0" xmlns="http://www.zend.com/server/deployment-descriptor/1.0">
<name>My demo app</name>
<summary>A ZF2 demo app</summary>
<description>A ZF2 demo app for the ContinuousPHP article</description>
<equals><![CDATA[E_ALL & ~E_NOTICE]]></equals>
Note that this example is informing Zend Server which PHP version the application requires, which extensions need to be loaded, and the value for
This file tells continuousphp which files to include in the package and the location of the various deployment scripts. If you want to exclude big folders in the package this is the place to do it.
Here’s an example of what a ‘deployment.properties file looks like:
appdir.includes = config,\
##Step 5: Pushing code down the pipeline
That’s it! Your continuous delivery pipeline is complete. From this point onwards, any commit, including merged pull requests, will initiate a new build. Your code will go through all the various stages from being cloned from the repo, to being packaged, tested and eventually deployed on the target you selected and defined.
You can overview the various stages of the pipeline by selecting the build on your project page. You can then see snapshots of the various stages as they are being processed and executed.
If at any stage the process fails, you’ll be able to see the precise error failing the build as well as being notified via email or the other notification channels you configured (e.g. Slack).
If all goes well with the deployment process, you’ll be seeing green lights all along the way, and eventually your new code is deployed on Zend Server. Conveniently, you don’t have to create a virtual host on Zend Server – continuousphp takes care of this automatically.
Open the Zend Server UI using the same URL you used for defining the deployment destination, and visit the Manage Apps page (Applications | Manage Apps).
Of course, once deployed on Zend Server, you can begin to use all the various available features for developing, debugging and monitoring your application.
The dual promise of speed and quality accompanying the Continuous Delivery approach is converting more and more development teams. But for developers, the task of fully understanding what Continuous Integration means, how it differs from a Continuous Deployment process, and how they both can fit into a Continuous Delivery cycle, can be daunting.
continuousphp could be a good way for PHP developers to get started. While there are many Continuous Delivery platforms out there, not many are focused entirely on PHP. The solution offered by continuousphp supports the methodologies and tools used by PHP developers and simplifies their integration into an easy-to-manage, fully transparent and reliable delivery pipeline.
Here are are some additional resources that can help you understand the solution offered by continuousphp and how to set up Zend Server:
- continuousphp documentation
- An introduction to continuous delivery
- How to run Zend Server on AWS
- Getting Started with Zend Server on Azure
- Zend Server documentation
Hope you enjoyed the read!