make chapter topic based instead of product based

This commit is contained in:
Markus Hausammann
2012-11-29 14:55:28 +02:00
parent e354d95842
commit 8f15552dec

View File

@@ -7,71 +7,36 @@ isChild: true
If you find yourself doing manual database schema changes or running your tests manually before updating your files
(manually), think twice! With every additional manual task needed to deploy a new version of your app, the chances for
potentially fatal mistakes increase. Whether you're dealing with a simple update, a comprehensive build process or even
a continuous integration strategy, build tools are your friend.
a continuous integration strategy, [build automation](http://en.wikipedia.org/wiki/Build_automation) is your friend.
### Phing - Deployment with XML and PHP
Among the tasks you might want to automate are:
* dependency management
* compilation, minification of your assets
* running tests
* creation of documentation
* packaging
* deployment
### Build Automation Tools
Build tools can be described as a collection of scripts that handle common tasks of software deployment. The build tool
is not a part of your software, it acts on your software from 'outside'.
[Phing](http://www.phing.info/) is the easiest way to get started with automated deployment in the PHP world.
With Phing you can control your packaging, deployment or testing process from within a simple XML build file.
Phing provides a rich set of tasks usually needed to install or update a web app and can be extended
with additional custom tasks, written in PHP.
Example of a Phing script (build.xml):
{% highlight xml %}
<?xml version="1.0" encoding="UTF-8"?>
<project name="my-project" default="update">
<!-- Prompt for environment and load respective buld properties. -->
<propertyprompt propertyName="environment" defaultValue="development"
promptText="What's the target environment (development, production)?" useExistingValue="true" />
<property file="build/properties/${environment}.properties" />
<!-- snip -->
<target name="update">
<phingcall target="svn-update" />
<phingcall target="update-dependencies" />
<phingcall target="make-configuration" />
<phingcall target="migrate-database" />
</target>
<target name="svn-update">
<trycatch property="error">
<try>
<svnupdate todir="." />
</try>
<catch>
<echo message="Svn update failed: ${error}" />
</catch>
</trycatch>
</target>
<target name="update-dependencies">
<exec command="php composer.phar self-update" />
<exec command="php composer.phar update" />
</target>
<!-- snip -->
</project>
{% endhighlight %}
### Capistrano - The powerful Ruby alternative
[Capistrano](https://github.com/capistrano/capistrano/wiki) is a system for *intermediate-to-advanced programmers*
to execute commands in a structured, repeatable way on one or more remote machines.
It is pre-configured for deploying Ruby on Rails applications, however people are **successfully deploying PHP systems**
with it. Successful use of Capistrano depends on a working knowledge of Ruby and Rake.
Dave Gardner's blog post [PHP Deployment with Capistrano](http://www.davegardner.me.uk/blog/2012/02/13/php-deployment-with-capistrano/)
is a good starting point for PHP developers interested in Capistrano.
###Chef - Ruby based system integration framework
[Chef](http://www.opscode.com/chef/) is more than a deployment framework, it is a very powerful Ruby based system
integration framework that doesn't just deploy your app but can build your whole server environment or virtual boxes.
@@ -93,34 +58,6 @@ done a great job of making continuous integration a reality even for small proje
integration service for the open source community. It is integrated with GitHub and offers first class support for many
languages including PHP.
Example of a Travis CI build script:
{% highlight yml %}
language: php
# list any PHP version you want to test against
php:
# aliased to a recent 5.3.x version
- 5.3
# aliased to a recent 5.4.x version
- 5.4
# optionally specify a list of environments, for example to test different RDBMS
env:
- DB=mysql
- DB=pgsql
# execute any number of scripts before the test run, custom env's are available as variables
before_script:
- if [[ "$DB" == "pgsql" ]]; then psql -c "DROP DATABASE IF EXISTS hello_world_test;" -U postgres; fi
- if [[ "$DB" == "pgsql" ]]; then psql -c "create database hello_world_test;" -U postgres; fi
- if [[ "$DB" == "mysql" ]]; then mysql -e "create database IF NOT EXISTS hello_world_test;" -uroot; fi
script: phpunit --configuration phpunit_$DB.xml --coverage-text
{% endhighlight %}
Further reading:
* [Continuous Integration with Jenkins](http://jenkins-ci.org/)