Deployment beta for Zend Server 5.5 – Getting Started

Deployment for PHP applications is one of those things where it’s tough to get a general reading on where things are.  On one hand you have people who have deployment mechanisms that seemingly automate the rotation of the earth and on the other hand you have people who jump up and down on their code trying to force it into a small hole (visions of Wile E. Coyote come to mind).  Others set up complex build procedures that has more processing on it than Cheez-Whiz (now I’m hungry for a grilled cheese sandwich).  My own thought on the matter is that for most PHP implementations a lot of the build tools out there are probably overkill for a lot of PHP applications.

Given all that, we have announced that we are making the beta for our new deployment feature in Zend Server 5.5 beta, available for download.  It’s not feature complete (there are some new features being worked on), but it provides the functionality needed for the 90% of us who do not have the need to have crazy complex deployment scenarios.

This begs the question, under what circumstances would the new deployment feature in Zend Server benefit you?

  • You simply copy files into production as part of your existing deployment mechanism using FTP (gasp), SFTP or rsync.
  • You do NOT want to maintain the infrastructure or tooling needed to deploy your application to production boxes (singly or in a cluster)

Zend Server deployment will be available for both Zend Server and Zend Server Cluster Manager meaning that you will be able to deploy applications to either a single server or to a cluster of servers with just a few clicks of the mouse.  We would like your help in looking at what works and what doesn’t.  Not just in the “what breaks” sense, but also in terms of the workflow and also the integration points, both in the Zend Server UI and also using the deployment API.

We would like to see innovative ways that you could use it, but it would probably help for you to see a quick example of how to do it to get you up and running quickly.  For that I have a short video that how you can utilize the deployment feature .


With that, let’s take a look at some of the things that you need to work with the deployment beta.

The first thing you need to be aware of is a program called zdpack.  This program helps to create the package to deploy to your Zend Server instance or cluster.  You can easily script it into an existing packaging routine or your can run it manually.  How you get it integrated into your own environment is up to you, but here are the steps that I used for my own testing.  These are not “best practices” necessarily.  There are variations in how you can do this, but if you want to start with a clean project (probably the easiest way to get familiar with it) this is a good way of doing it.

Step 0: Download the Zend Server 5.5 beta

Windows or Linux

Step 1: Create a Zend Framework project

The reason I chose Zend Framework instead of a PHP project was because a Zend Framework project (in Zend Studio) has an internal document root folder called “public” where the public files are stored and the source code of the application, configuration files and such are stored outside of the document root.  Those are some of the reasons why I prefer using a ZF application for this.  The other reason is that when we build out the deployment skeleton, having the document root one directory lower allows you to write your deployment hooks easily in the same project as well as restricting access to the deployment config file.

Step 2: Create a deployment skeleton

Open up a CLI and go to the main workspace and type

zdpack create ProjectName

replacing “ProjectName” with the name of your project.  This will create a few files and directories in your project.  You can do this outside of a project, or anywhere on your computer for that matter.  But this just makes it easy to get started.  Your project should look something like the image on the right.  The red highlighted areas are files that the zdpack application created.

In the root directory of your application it will have created the directories “data” and “scripts”.  Inside of scripts you will see templates for individual files that allow you to run deployment commands at various points along the deployment process.  One that I created was a hook that would send an email each time the application was deployed.  I put the following code into the post_activate.php

require_once 'Zend/Mail.php';
$mail = new Zend_Mail();
$mail->addTo('[email protected]');
$mail->setSubject('New deployment');
$currentAppVersion = getenv('ZS_CURRENT_APP_VERSION');
New application has been deployed.
Version: {$currentAppVersion}

The most important line is the $currentAppVersion.  Any data or meta data that you want will want will be made available via environment variables.

Step 3: Modify the deployment.xml file

The deployment.xml file in the main directory contains the meta information that the deployer needs to get your application up and running.  Here is a screenshot of what that might look like.  Most the elements are self descriptive and so I won’t spend much time talking about them, but there are a few things I would like to highlight.

First of all, the highlighted elements on the bottom-right side of the page.  This is the XML editor in Zend Studio and as you can see you are limited to the names of the nodes that you are able to enter into the deployment file at various node positions due to the validation that occurs.  This actually makes it easy for you to create a deployment file in a simple XML editor.

The second (more important) thing I want to direct your attention to are the three nodes on the left.  The first is the “eula” node.  If you have an end user license agreement you put the location of it there.  The second one is “appdir”.  When you first create the deployment.xml file the directory “data” will be in there, which is where the deployer is expecting the base of the application to be.  But if you are following this example then the base of the project is technically the base of your application.  That is why I put the value “public” in the “docroot” node.  These are all relative paths to the base of the application directory.

Step 4: Create the deployment package

Going back to your CLI in the main workspace directory type in

zdpack pack <ProjectName>

This will create what is basically a zip file with an expected file structure. The file is called a zpk, but it’s really just a zip file.

Step 5: Deploy

Log in to the Zend Server GUI and click on the new “Applications” tab.  On the right hand side of the screen you will see a button that says “Deploy Application”.  Click on that button and follow the instructions.  When you get to the end of the wizard click “Done” and your application will start to deploy.

That’s it.

Where to go from here

Try it.  Go to the download page and install it.

Check to see if there are better ways of integrating it with your application than what I have noted here.

Go to the forum.  Report bugs.  Download sample deployment applications.

As I said earlier there are more features coming in the near future but there is definitely enough for you to get cracking on it.  I’m actually quite happy to see this new feature being added.  Yes there are definitely alternate ways of deploying your applications.  But in the experimentation I have done I have found that this is a nice, simple, easy to use method for deploying your PHP based applications.

22 Thoughts to “Deployment beta for Zend Server 5.5 – Getting Started”

  1. Very excited to see this type of feature being added to Zend Server. I will play, but maybe you have a quick answer; what would the work flow be if my project was under a version control system like sun or git. As to push package the meta files?

    1. Under version control you would script the execution of zdpack. I believe we’re working on connectors to various source and build systems. However, if that is something you’d like to play with yourself you could always post your scenario to the forum, see if it’s something we’re working on, and if not, provide requirements or even script out an example that we might be able to include for others who are doing the same things as you.

    1. In and of itself, no, but that is something that you could quite easily script during one of the deployment hooks

  2. It’s going to be interesting to see this get built out over time. Personally I am still using phing. But this is something that is going to be great a few versions from now. Writing build scripts is a pain so seeing this get incorporated into Zend Studio in an intuitive way will go a long way. Applauds on support for more than Zend Apps.

  3. Great start! Php Deployment have always been a struggle, you are correct, most of the existing tools are overkill. I’d like to see features such as source control integration (namely, SVN and GIT). This may be a longshot, but some sort of db deployment would be nice too.

    How does the update work? does it check for modified files or does it simply overwrite everything?

  4. Very nice indeed. Some question anyway:
    Will the Framework and the Concept be open sourced?
    I mean, while the principe is in place will people be allowed to hack it, enhance it, create plugins, and use it without Zend Server but still with zfpack or will you enforce some licenses to forbid third parties (such as open source) integration?
    Because the concept could be really smoothly integrated with ant, phing… and any other continuous integration tool already in place.
    The only thing that will then need to be maintained is a good documentation of the concept and rules + framework versioning.

    1. It won’t be open sourced, but it will definitely be extendable. Most of it runs off of scripts that you can easily hook into yourself and I have also been dabbling in building my own OO approach to handling deployment. It will require Zend Server since the deployment mechanism itself is handled from within the Server binaries. But the intention is to make it easy to integrate with ant, phing, Jenkins, etc. with as little effort as possible.

  5. Hi Kevin,

    This is just what I was waiting for !

    Congratulations to the team.

    Btw, is it possible to deploy a package using the command line ?

Leave a Reply

Your email address will not be published.