Forum d'entraide PHPFrance

Suite à mon billet, j'ai réussi un premier draft qui fonctionne pas mal, donc je vous en fait profiter.
Le code permet de faire des mises en production avec les dossiers, tout en permettant un rollback rapide...
Beaucoup d'évolution sont possibles suivant l'imagination

// Dossier ou seront deposees les export/backup
$baseLocale = '';

/**
 * Informations de connexion au serveur FTP
 */
$hoteFTP = '';
$loginFTP = '';
$passFTP = '';
// Dossier dans lesquel se trouve les fichiers
$baseDossierFTP = '';

/**
 *  Definition des dossier de base (mep pour la mise en production, backup pour effectuer le backup)
 */
$baseMep = $baseLocale.'mep-'.$revision;
$baseBackup = $baseLocale.'backup-'.$revision;

// URL du serveur de subversion
// exemple : svn://monsubversion/
$urlBaseSVN = '';

// Nom du projet ex : projet1
$projet = '';

// Numero de la revision correspond au fichier a recuperer
$revision = 1;

// exemple : svn://monsubversion/projet1/
$svn = $urlBaseSVN.$projet;
$cmd = "svn diff --summarize -r ".$revision." ".$svn;
exec($cmd, $tabRetour);

/**
* Recuperation des fichiers du SVN
*/
mkdir($baseMep);
chdir($baseMep);
foreach($tabRetour as $unFichier) {
	$newInfo = str_replace(' ', '',$unFichier);	
	$type = substr($newInfo, 0, 1);
	$nomFichier = substr($newInfo, 1);
	if ($type == 'M' || $type == 'A') {
    	if (ereg('(\.)', $nomFichier)) {
    		$tab = explode($projet, $nomFichier);
        	$folder = $tab[1];
        	$tabFolder = explode('/', $folder);
        	array_pop($tabFolder);
        	foreach ($tabFolder as $sousDossier) {
        		if (!is_dir($sousDossier)) {
        			mkdir($sousDossier);
        		}
        		chdir($sousDossier);
        	}
    		$cmd = "svn export ".$nomFichier;
        	exec($cmd);
        	echo '(GETSVN) Export fichier '.$folder."\n";
        	chdir($baseMep);
        	$tabFichier [] = $folder;
    	}
	}
}	

/**
 * Creation du backup - recuperation des fichiers sur le FTP
 */
mkdir($baseBackup);
chdir($baseBackup);
$stream = ftp_connect($hoteFTP);
ftp_login($stream, $loginFTP,$passFTP);
foreach($tabFichier as $fichier) {
	$tabFolder = explode('/', $fichier);
	array_pop($tabFolder);
	foreach ($tabFolder as $sousDossier) {
		if (!is_dir($sousDossier)) {
			mkdir($sousDossier);
		}
		chdir($sousDossier);
	}    	
	chdir($baseBackup);
	ftp_get($stream, $fichier, $baseDossierFTP.$fichier,FTP_BINARY);
	echo '(BACKUP) Recuperation fichier '.$fichier."\n";
}
/**
 *  Envoi des fichiers pour Mise en production
 */
chdir($baseMep);
foreach($tabFichier as $fichier) {
	ftp_put($stream, $baseDossierFTP.$fichier, $fichier, FTP_BINARY);
	echo '(MEP) Envoi fichier '.$fichier."\n";
}
ftp_close($stream);

Hey ,

Pourquoi ne pas utiliser les hooks de SVN, notamment le post-commit ? Ce hook reçoit en second paramètre le numéro de révision. Il est facile d'exporter les nouveaux et de faire un backup des anciens, le tout en Shell. On s'appuierait sur la commande svnlook par exemple pour obtenir la liste des chemins modifiés pour une version précise.

Pour mettre en place les hooks, tu peux aller dans le dossier de ton dépôt : repos/hooks/ et tu y trouveras des exemples (en .tpl si mes souvenirs sont bons).

Tu peux évidemment écrire tes hooks en PHP hein. Il suffit de commencer le fichier par #!/usr/bin/php par exemple. Enfin après, je te laisse te débrouiller .

Hello Hywan,
Je ne veux pas que le SVN pilote le déploiement des applications, mais plutôt l'utilisateur.
J'utiliserais plutôt ton cas de figure pour effectuer des déploiements sur des plateformes de tests, mais pas sur des plateformes de production. Je vais tout de même me pencher dessus, ça a l'air très intéressant.
Mon but est de faire un backup et un déploiement de fichier sur un serveur de production. Tout ceci permettant une action automatique et un retour en arrière plus rapide.

J'utilise ce système sur des serveurs de production en fait. Et SVN te permet déjà un rollback facilement. Tu devrais te pencher sur : svn merge --commit -r [REV], et svn update -r [REV] je pense .

Bonjour Alkann,

A propos de la phrase "Je ne veux pas que le SVN pilote le déploiement des applications, mais plutôt l'utilisateur", peux tu nous donner la/les raison(s) qui t'ont fait prendre cette première position. je suis très partagé entre ton idée première et le fait de piloter la mise en production de façon automatisé avec svn. Les deux solutions ont à mes yeux des avantages (+) et des inconvénients (-)

Mise en production par svn :
+ automatisation simple et riche en fonctionnalité de la procédure de mise en production grâce à la syntaxe des commandes svn
- Présence des répertoires .svn sur le serveur de production (espace disque occupé par mon projet avec les .svn : +100%)
- Nécessite une utilisation rigoureuse et cohérente de subversion par les développeurs.

Export et mise en production par un shell utilisateur :
+ Solution "light" : rapide au déploiement (mise en production + rollback)
- Développement propriétaire à produire donc non standard pour mise en place du batch. (source d'erreur)

>> As tu des arguments différents pour compléter l'idée du déploiement des applications par l'utilisateur ?

versionning != backup, on ne devrait jamais utiliser un outil de versionning pour faire des backups mais un software de backup.

http://fr2.php.net/manual/fr/book.svn.php

Je pense que le terme de "backup" est mal choisi, mais, en cherchant plus loin, le principe même du versionning s'apparente de près à de la sauvegarde.
Toutefois, je rejoins Nagol sur le fait que la mise en place d'un gestionnaire de version ne permet pas de s'affranchir de la mise en place d'un système de sauvegarde avec redondance.

Je pense que le terme de "backup" est mal choisi, mais, en cherchant plus loin, le principe même du versionning s'apparente de près à de la sauvegarde.
Toutefois, je rejoins Nagol sur le fait que la mise en place d'un gestionnaire de version ne permet pas de s'affranchir de la mise en place d'un système de sauvegarde avec redondance.

ce n'étais pas mon propos, en fait en utilisant un système de versionning comme un système de backup on gâche juste entièrement l'interêt d'avoir un système de versionning:

retrouver un changement précis et la personne qui l'a fait
récupérer un fichier précis à une date donnée, ou pour un commit donné
avoir en permanence dans head une version fonctionelle peut etre sous-testée mais fonctionelle

le système de versionning ne s'apparente en rien à du backup, le backup c'est la sécurité des données c'est tout à fait différent.