Zend FR

Bonjour,

Moi j'utilise principalement svn. Je trouve ça pratique et robuste. C'est pas vraiment fait pour, mais ça marche bien. En cas de modification en prod (pour un incident majeur par exemple), c'est facile de réintégrer les modifs dans le code du dev... La gestion de branches permet d'avoir des versions différentes en prod et en dev...
Bref, c'est ma solution fétiche... (attention, penser à modifier sa conf apache pour que les .svn ne soient pas lisibles par apache, sinon c'est un beau trou de sécurité...)

Quand un hébergeur ne me laisse pas utiliser svn (chez certains clients ça arrive), j'utilise svn en dev et en validation pour le suivi de version. Ensuite phing pour les déploiements.

A+, Philippe

Bonjour,

Tu peux ajouter ça

<Directory ~ "\.svn">
  Order allow,deny
  Deny from all
</Directory>

A+, Philippe

Bonjour,

l'autre option pour ne pas être embarassé par les dossiers .svn est d'utiliser un "export" et non pas un checkout pour la mise en production.

Export va simplement extraire tous les fichiers, dans leur dernière version, sans créer les dossiers .svn, ce qui veut dire que si l'on fait des modifs dans des sources exportées, on ne peut pas les remonter au serveur avec un "commit". Mais comme justement il n'est pas recommandé de modifier les sources en prod, ça évite d'être tenté

Il est possible d'automatiser le processus d'export pour passer en production avec un outil comme phing (http://phing.info/trac/), qui permettra outre l'export des sources proprement dites d'automatiser certaines tâches (vidage du cache, modification de l'environnement, réglages des droits d'accès aux fichiers etc.)

Pour les exports, je ne suis pas un expert du fonctionnement. Par contre si tu fais la méthode avec une copie locale sur ta prod (avec les .svn). Il suffit d'ajouter un svn:ignore sur tes répertoires de données et ils ne sont plus affectés par svn... (par contre sur tes données, tu n'a bien sur pas de versionning avec svn...)

Dans le cas d'un svn export, je laisse gauthier répondre...

A+, Philippe
PS : en général, mes données ne sont pas dans l'arbo de mon code. Dans ce cas le problème ne se pose pas. Cela dit ça n'est pas tjrs possible, surtout quand les hébergeurs sont des furieux, fans d'open_basedir très restrictifs....

Solution 2 pour moi (avec en plus une copie locale en prod et je fais aussi un svn update en prod pour mettre à jour).

A+, Philippe

concernant la fonction export de SVN, elle permet d'exporter soit ses sources courantes (depuis sa copie de développement) soit depuis le repository directement (par exemple après un dernier commit et la création d'un tag - ou release - si on veut passer en prod).

Dans le cas d'un export depuis sa version de développement, si des fichiers qui ne font pas partie du repository sont présents dans l'arborescence, ils ne seront pas copiés. En revanche, les fichiers déjà présents sur la cible ne sont pas sensés être supprimés

Perso cela me semble une meilleure pratique que de n'utilsier que cette fonction depuis des tags (versions figées dans le repository) pour garantir le meilleur fonctionnement de l'appli/du site en production. On sera par exemple certain de la version du code en cours d'utilisation, ce qui permettra plus facilement en cas de découverte d'un bug tardif de revenir sur cette version (grâce au tag) et de s'atteler à corriger le bug en question sans s'encombrer des ajouts et modifications survenus entre-temps.

Bien sûr, cela reste à mettre en rapport avec l'ampleur du projet ! Si 'lon parle d'une petite appli, dont on est le seul responsable... allons-y pour le co suivi d'update

Mais si l'on parle d'un projet d'importance développé pour un client, ou bien au sein d'une grande entreprise, la solution tags+export permet de faciliter le suivi des applications, et de se conformer plus facilement à de bonnes habitudes... on évitera par exemple de mettre en ligne un code non-testé, ou non-validé.

Une fois encore, combiné à l'emploi de phing, le passage du dev ou de la pré-prod à la prod basé sur des exxports svn est très simple ("./phing monsite.xml" peut suffire, ce qui n'est guère plus long que "./svn update" ), et permet de bien mieux contrôler et automatiser sa mise en prod.

Merci Gauthier pour cette réponse détaillée.

gauthier a écrit:

Une fois encore, combiné à l'emploi de phing, le passage du dev ou de la pré-prod à la prod basé sur des exxports svn est très simple ("./phing monsite.xml" peut suffire, ce qui n'est guère plus long que "./svn update" ), et permet de bien mieux contrôler et automatiser sa mise en prod.

Est que tu lance "./phing monsite.xml" sur le serveur de dev puis celui-ci fait l'export d'un tag et l'upload en ftp sur le serveur de prod ?

gauthier a écrit:

le mieux consiste à exécuter phing sur le serveur de prod, ce qui permet de s'épargner le ftp (j'aime pas les ftp)

Humm ok, j'ai plus qu'a essayer ça .

Merci.

Bonjour Bertra,

Est ce que cela signifie que tu as un client SVN sur ton serveur de prod, que tu fais un update, et que tu utilises phing par la suite pour déployer dans le répertoire de l'application ?

C'est ça à un détail près : il n'est pas nécessaire de faire d'update La directive export de SVN permet directement d'extraire d'un repository, y compris distant. Voici un exemple simpliste de fichier de configuration phing :

<?xml version="1.0"?>
<?xml version="1.0"?>
<project name="PhingTest" default="build">
    <target name="build">
        <echo msg="Export des sources du Zend Framework..." />
        <svnexport
            repositoryurl="http://framework.zend.com/svn/framework/standard/trunk"
            todir="/var/tmp/zf"
            force="true" />
    </target>

    <target name="archive" depends="build">
        <echo msg="Création de l'archive zf.tgz..." />
        <tar destfile="./zf.tgz" compression="gzip">
            <fileset dir="./zf">
                <include name="*" />
            </fileset>
        </tar>
    </target>
</project>

copiez ce code dans un fichier build.xml (nom de fichier de config cherché par défaut par phing), puis exécutez le :

// pour exporter les sources de phing depuis osn repository svn :
phing
// ou, pour exporter les sources et générer une archive phing-latest.tgz :
phing archive

Tout simplement

Notez que phing peut bien entendu également déclencher un update plutôt qu'un export si vous y tenez

Pour installer phing, le plus simple consiste à utiliser pear :

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

Et voila, j'arrête là ce mini-tuto ; si vous voulez en savoir plus, go to http://phing.info

Je t'en prie

Je dirais que ça a 3 avantages :
- c'est standard. Si quelqu'un voit un build.xml qui traine, c'est assez simple à lire et il sait quoi en faire
- pour des déploiements plus complexes, il y a un système de dépendance hyper efficace. C'est souvent très pratique.
- ça simplifie la vie pour des tâches courantes dans un déploiement (parcourir des répertoires, exclure ou include des fichiers, synchroniser des arbo, transférer par ftp, ssh,...)

A+, Philippe