pear channel-discover pear.phing.info
pear install phing/phing

pear upgrade phing/phing

<?php
echo 'hello world';	
?>

<?php	
phpinfo();
?>

<?xml version="1.0" encoding="UTF-8"?>

<project name="SimpleHelloworld" basedir="." default="build">
    <target name="build">
        <echo msg="Debut du build" />
        
        <echo msg="Création du répertoire build" />
        <mkdir dir="./build" />
        
        <echo msg="Création du répertoire release" />
        <mkdir dir="./build/release" />
        
        <echo msg="Copie du fichier helloworld.php vers build/release/helloworld.php" />
        <copy file="helloworld.php" tofile="./build/release/helloworld.php /">
        <echo msg="Fin du build" />
    </target>
</project>

Buildfile: D:\Programings\Projects\0019-PhingDiscoveryArticle\svn\trunk\app\01-simple-helloworld\build.xml

SimpleHelloworld > build:

     [echo] Debut du build
     [echo] Creation du repertoire build
    [mkdir] Created dir: D:\Programming\Projects\0019-PhingDiscoveryArticle\svn\trunk\app\01-simple-helloworld\build
     [echo] Creation du repertoire release
    [mkdir] Created dir: D:\Programming\Projects\0019-PhingDiscoveryArticle\svn\trunk\app\01-simple-helloworld\build\rel
ease
     [echo] Copie du fichier helloworld.php vers build/release/helloworld.php
     [copy] Copying 1 file to D:\Programming\Projects\0019-PhingDiscoveryArticle\svn\trunk\app\01-simple-helloworld\buil
d\release
     [echo] Fin du build

BUILD FINISHED

Total time: 0.4153 seconds

<project name="SimpleHelloworld" basedir="." default="build">

<target name="build">

<echo msg="Debut du build" />

<mkdir dir="./build" />

<copy file="helloworld.php" tofile="./build/release/helloworld.php /">

Qu'est ce que c'est ?
----------------------

Cet exemple présente un build simple permettant
d'auto archiver chacune de ses releases. Ce build est adapté à
des petits projets où vous travaillez seul.

Le fichier build.xml propose les opérations suivantes
 # Déploiement de l'application dans l'environnement de debug
 # Déploiement de l'application dans l'environnement de release et création 
    d'un package avec le numéro de version (Si un package existe, il ne sera pas
    remplacé et le script affichera un message d'erreur)
 # Déploiement forcé de l'application dans l'environnement de release et
    création /remplacement d'un package avec le numéro de version
 
Pour changer le numéro de version, vous devez éditer le fichier build.xml.

Pour un simple helloworld, ce déploiement est trop lourd mais vous pouvez l'adapter
à la majorité de vos applications. Les prérequis sont peu nombreux. 

Quels sont les fonctionalités de Phing utilisés ?
--------------------------------------------------

Les fonctionnalités de Phing utilisées sont :
- AvailableTask : Vérifier qu'un dossier ou un fichier est disponible
- CopyTask : Copier un ou des dossiers / fichiers
- DeleteTask : Supprimer un ou des dossiers / fichiers
- ExitTask (FailTask) : Arrêter l'exécution d'un script
- Fileset : Balise xml pour définir les fichiers concernés par une tache
- IfTask : Prise de décision durant le build
- PropertyTask : Utiliser des variables permettant de modifier 
    la configuration du build
- Target : Utiliser des targets dépendantes les unes des autres
- ZipTask : Compresser un ou des dossiers / fichiers grâce à l'algorithme Zip 
    dans un seul fichier

Qu'est ce que c'est ?
----------------------

Cet exemple présente un build plus complexe exécutant les tests unitaires
PHPUnit, vérifiant que le code respecte la convention de code du projet PEAR 
grace à PHP_CodeSniffer et génère la documentation de l'API en utilisant PhpDoc.

Comme dans les projets précédents, nous allons sortir un package au format zip
incluant le numéro de version, la date de l'exécution et le statut des tests 
unitaires qui ont été exécutés.

Le nom du package se présentera de la façon suivante
NomDuProjet-Version-YYYY-MM-DD-hh-mm-ss-TestsResult

Sur ce type de projet, l'emploi d'un serveur de version serait un gros plus.
Pour cet exemple, nous allons volontairement l'omettre pour raisons de facilité de
mise en oeuvre.

Note : Dans la pratique, si vous n'avez pas de serveur de versionning, vous 
pouvez figer votre environnement dans une archive en excluant le dossier contenant
tous les packages de release. Ainsi, vous pourrez revenir à une version differente
de votre developpement en quelques clics. Vous pourrez egalement utiliser un outil
tel que winmerge pour comparer vos 2 versions de votre projet. Il ne s'agit que 
d'un paliatif valable si vous travaillez seul, un serveur de versionning reste
idéal et rends beaucoup plus de services que le simple archivage.

Dans cet exemple, vous découvrirez une méthode pour factoriser le code 
commun à chacun de vos builds dans un fichier séparé (Utile dans le cadre de l
industrialisation de vos projets)

Le fichier build.xml propose les opérations suivantes
 # Exécution des tests PHPUnit
 # Exécution des tests PHP_CodeSniffer (Le fichier app/function.php declenche 2
    warnings)
 # Génération de la documentation d'API
 # Exécution de toutes les operations de quality assurance (documentation, tests)
 # Déploiement de l'application dans l'environnement de debug
 # Déploiement de l'application dans l'environnement de release
 # Packaging de l'application au format ZIP
 
Quels sont les fonctionalités de Phing utilisés ?
--------------------------------------------------

# PhingTask : Vous pouvez appeller une target dans un autre fichier de build
    Utile pour factoriser le code de vos builds;
# PhpUnitTask : Vous exécutez les tests unitaires grace à cette tache. C'est 
    non compatible avec les suites de tests. Phing construit ces propres suites;
# PhpCodeSnifferTask : Vous vérifiez avec cette tache le style de votre code
    grace à PHP_CodeSniffer;
# PhpDocumentorTask :  Vous pouvez générer la documentation de l'API de votre
    code et la génération de documentation à base de docbook avec Phpdoc.