Michel Belleville wrote: > Ca peut provenir du fait que je débute avec Capistrano et que je n'ai > pas tellement l'habitude de déployer des applications rails. > > Je veux que mon appli sur github reste clean et standard (c'est un > genre de projet-démo), ce qui exclue les modifications spécifiques à > mon hébergement (/public/displatch.fcgi par exemple), celles propres à > mon utilisation personnelle (titre du site, mot de passe > administrateur, ...) et bien entendu les données sensibles > (configuration de la base de données, informations de déploiement, > ...), et tout ce que j'ai vu comme solutions de déploiement par > Capistrano en utilisant un système de contrôle de version parle > configurer Capistrano pour le faire récupérer les sources à déployer > sur le repository distant (sauf si j'ai mal compris mais j'avoue que > pour un novice les explications ne carrément pas clair dans la > majorité des tutoriaux pour Capistrano). > > Ce n'est pas ce que je veux, ce que je veux c'est faire une branche > locale (sur ma machine de développement), y mettre les indications de > déploiement (pour les garder versionnées), y faire les bidouilles > (fichiers de configuration, tweaks spécifiques à l'hébergeur, ...) > pour qu'elles aussi soient versionnées, et faire envoyer le tout (avec > scp ?) sur le serveur par Capistrano, sans que ma branche spécifique > ne touche à mon repository github pour ne pas le polluer. > > Le problème, c'est que je ne vois pas comment faire effectuer cette > dernière étape par Capistrano. > > Je ne sais pas si c'est plus clair là. > > Sinon je suis preneur pour ta solution alternative. Comment ça marche ? Ok, je vois un peu mieux et ton système n'est pas jouable. En effet, tu n'as pas de maitrise locale de ton projet. Mais tu peux tout à fait avoir un versionning de tes conf. Voici la technique à adopter :
1) tout ce que tu souhaites mettre configurable doit être dans le dossier /shared/ 2) tu ajoutes une régles post deploy:update_code qui copie les fichiers de configuration de shared dans les bon endroits. par exemple pour Typo, il faut copier les fichier : database.yml, mail.yml et le dossier /public/files/ En général, on a tendance a faire un lien symbolique pour limiter le nombre de source et aussi modifier qu'un seul fichier sur le serveur. Grâce à cette régle, tu fais ce que tu souhaitais faire en local sur le serveur. C'est la méthode la plus commune. J'explique sommairement la technique sur mon blog(http://blog.shingara.fr/2007/09/28/deployer-un-blog-typo-grace-a-capistrano2) en prenant comme exemple le déployement d'un blog Typo qui a l'époque était sous SVN. Sinon, je partage régulièrement mes fichiers de déployement de logiciel opensource (http://blog.shingara.fr/tag/capistrano) J'espère avoir un peu répondu à ta question. -- Cyril Mougel http://blog.shingara.fr --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
