Impacts on Release Management

Release Management: We are keeping our shell scripts.
We have to improve the scripts, so that they:

• put the current application version and id into the index.php(s)
• merge the SQL files as described in the database section.
• Provide the meta data for the updater
• prepare the release history, distilled from git log

We have to provide additional meta information on our release server. This would in special be the autoupdate flag. Only Packages which are autoupdateable can be applied automatically through our updater.
Also checksums of the external libraries must be calculated in our build process.
Since only major releases are installable, the DB Structure has only to be done for majors.

Refactor current SQL File location: move all sql files from the “docs” directories to own “database” directories:

Editor Module:

/database/001-foo.sql
/database/002-foo.sql
/database/003-foo.sql

Default Module / main application directory:

/database/001-bar.sql
/database/002-bar.sql
/database/editor/001-foo.sql ← using sub directories with the name of other modules gives us the possibility to explicitly overwrite the specified editor SQL file with application specific DB changes.

Definition of Minor and Major Release

Definition for versioning see: http://pear.php.net/manual/en/guide.users.concepts.version.php

Creating a major version (for example 1.1.0)

When creating a major version, the build script needs access to the database to create the structure file of the major release.
That means:

1. import 000-structure.sql file from previous major release in a fresh “build” database.
2. Copy the alter files from each module database directory to the buildtarget database directory.
   1. The alter files have to be filtered: Copy only the alter files which are not already used in previous versions (check all existing major directories, or track the file names in a file)
   2. “merge” all affected SQL files distributed over all modules together:
      /editor/database/001-foo.sql → /build_target/database/1.1/0001-editor-001-foo.sql
      /database/???-foo.sql → /build_target/database/1.1/0002-default-???-foo.sql
      /database/editor/???-foo.sql → /build_target/database/1.1/0003-editor-???-foo.sql
   3. Last example shows possibility to overwrite SQL files from submodules.
   4. The target filenames are build up of three parts: "0001-editor-001-foo.sql". The single parts of the name are:
      1. 0001 → a unique counter for this release. Through this counter the order of the files to be imported can be managed. The order is computed from the optional meta information files which keeps information about the dependency of the SQL file. If no information is given the file depends on the next lower file of this module.
      2. editor → the module where this file comes from
      3. 001-foo → the original name of the file in the source module, so it can be tracked back in the develop system.
3. Apply all copied SQL files to the “build” database
4. fill up db_versions table in the build database with all alterfiles, so that they wont get imported automatically.
5. Export the new structure to /build_target/database/1.1/000-structure.sql

Creating a minor version (for example 1.1.1)

Minor Versions do not deliver an own structure.sql, they only deliver the alter files.
So call only step 2. from major versions here. We are staying in directory 1.1, that means we dont create a own directory for the minor version.

Other Resources:

Phing

Phing should only be considered as build system. Currently we are staying on our own shell build scripts.
The in phing available DbDeploy is also the wrong tool for us. It produces one big alter file out of smaller ones, and tracks which files are already merged. We need a feature which tracks each installed file per installation.
Input to phing:
http://systemsarchitect.net/deploying-php-applications-with-phing/
http://stackoverflow.com/questions/2453887/getting-phings-dbdeploy-task-to-automatically-rollback-on-delta-error

PEAR / Pyrus

with phing, should we use also composer (https://getcomposer.org/)?

Information on PEAR uage
http://stackoverflow.com/questions/11053699/using-pear-to-deploy-a-php-web-app
http://semanticscuttle.sourceforge.net/pirum.html
http://www.eschrade.com/page/deployment-pear-4c228790/

Creation of a PEAR channel:
http://pirum.sensiolabs.org/
http://blog.stuartherbert.com/php/2011/03/30/setting-up-your-own-pear-channel/
without pirum: http://pear.php.net/manual/en/guide.users.dependencytracking.generatingpackagexml.php
or with pyrus itself:
http://pear.php.net/manual/en/pyrus.commands.make.php

In general:
http://de.slideshare.net/shahar/best-practices-inphpappdeployment
Using Zend Server und Zend Server Deployment?
http://de.slideshare.net/shahar/best-practices-inphpappdeployment