Understanding the Package Structure

Your .zpk package contains the data, scripts, and an XML descriptor file for your application.

Data - Your application (all the source code files of your application).
Descriptor File - This XML file, which is defined by an XSD file, describes all necessary information in order to deploy your application using Zend Server’s deployment feature. For an example of the descriptor template see The XML Descriptor File.
It contains three parts:

name - (Required) The application's name.
summary - The application's short description.
description - The application's long description.
version - (Required) The application's version number.
eula - The EULA file.
appdir - (Required) The applications directory. By default, this is the data folder of your package.
docroot - The alias will point to the directory you specify.
scriptsdir - The directory in which your scripts are located. By default, this is the scripts folder of your package.
healthcheck - Add the relative URL you would like Zend Server to check against for Application Health Check. This checks if the URL returns a 200 (OK) response or an error response.
variables - Define environment variables for the deployment scripts.

Dependencies which need to be satisfied in order for the application to function correctly. For example, PHP version and PHP directive values.
User parameters that are required for the application’s deployment. For example, database name. These, along with the values you define, will appear in the User Parameters dialog during deployment. For more information see Deploying an Application.

Scripts (PHP hook scripts) - Zend Server deployment consists of six actions: two for deployment, and two for removal. Two hook scripts are provided for each action (pre and post), allowing you to customize the actions according to your needs.

Stage - Place the contents of the .zpk application package on the server or on the cluster nodes.

Pre-stage - All customized actions that must be executed before the staging process begins.
Post-stage - All customized actions that must be executed after the staging process ends.

Activate - Perform the final steps necessary to make a staged application public.

Pre-deactivate - All customized actions that must be executed before deactivation.
Post-deactivate - All customized actions that must be executed after deactivation.

Un-stage - Cleans up your server and deletes any files that were relevant only to the now deactivated application.

Pre-unstage - All customized actions that must be executed before the un-staging process begins.
Post-unstage - All customized actions that must be executed after the un-staging process is completed.

See Preparing the Package Using the Deployment Tool to learn how to build your application package.

Hook Script Examples

The following is a list of examples of operations that may be defined in each hook script:

Pre-stage - Validate and applying user customized parameter values, verify the existence of generic prerequisites, etc.
Post-stage - Create a new database schema, modify a file or directory permissions on staged source files, etc.
Pre-activate - Upgrade an existing database schema, etc.
Post-activate - Remove a temporary banner ("Down for Maintenance"), reset a cache, etc.
Pre-rollback - Return configuration files or the database to their previous verstion, etc.
Post-rollback - Take the site out of maintenance mode, return the load balancer settings, etc.
Pre-deactivate - Put up a banner ("Down for Maintenance") for the previous version, etc.
Post-deactivate - Modify external configuration files, etc.
Pre-unstage - Back up specific applications files such as audit logs and other data files, etc.
Post-unstage - Clean up external files referencing the application (which are no longer needed), etc.