Forum: Rails France Déployer d'un répository local avec Cap istrano

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Michel B. (Guest)
on 2009-02-13 13:37
(Received via mailing list)
C'est sans aucun doute la question innocente d'un développeur qui n'y
connait pas beaucoup en administration système, mais je suis en train de
ramer grave pour trouver de l'information sur ce sujet précis.

Tout d'abord, un peu de backstory :

J'ai une petite appli que je versionne sur un petit github publique, et
je
veux la déployer sur mon serveur DreamHost. Déployer sur un serveur
github,
c'est toute une histoire, il faut tuner les fichiers .htaccess, fastcgi,
etc., et je n'ai pas envie de le recommencer à chaque fois que je
déploie
(et dans les prochaines semaines je risque de déployer souvent). J'ai
donc
choisi Capistrano pour gérer le gros du boulot. J'ai commencé par
chercher
de l'info, et je n'ai trouvé des explications que pour faire ça :

[copie locale] => [repository distant] => [serveur de déploiement]

Et ça ne me plait pas trop, parce que :
- je ne veux pas que les login passwords d'administration de mon serveur
soient disponibles dans mon repository github
- je n'ai pas envie de polluer mon repository distant avec des tweaks
spécifiques à l'hébergeur
- je n'ai pas envie de me fader la configuration et l'administration
d'un
repository git ouvert et sécurisé supplémentaire depuis ma machine de
développement
- je vais customiser mon appli pour mon usage spécifique (style, images,
etc.) et je ne veux pas non plus polluer mon appli générique avec mes
tweaks
persos

Ce que j'aimerai :

[copie locale:branche locale spécifique] => [serveur de déploiement]

Comme ça la branche locale peut prendre les tweaks spécifiques qu'elle
veut,
tant qu'elle n'est pas poussée sur github pas d'inquiètude pour la
sécurité
de mes mots de passe, etc.

Mais voilà, ça fait environ 2 jours que je cherche de l'info pour ça, et
ça
n'a pas vraiment l'air d'avoir passionné les éditeurs de tutoriaux (même
ceux de Capistrano en fait), j'imagine que ça doit être trop simple mais
comme je débute avec Capistrano...

Donc si quelqu'un peut m'indiquer par où commencer, je suis preneur.

Michel B.
Cyril M. (Guest)
on 2009-02-13 13:51
(Received via mailing list)
Michel B. wrote:
> chaque fois que je déploie (et dans les prochaines semaines je risque
> spécifiques à l'hébergeur
>
> Comme ça la branche locale peut prendre les tweaks spécifiques qu'elle
> veut, tant qu'elle n'est pas poussée sur github pas d'inquiètude pour
> la sécurité de mes mots de passe, etc.
>
> Mais voilà, ça fait environ 2 jours que je cherche de l'info pour ça,
> et ça n'a pas vraiment l'air d'avoir passionné les éditeurs de
> tutoriaux (même ceux de Capistrano en fait), j'imagine que ça doit
> être trop simple mais comme je débute avec Capistrano...
>
> Donc si quelqu'un peut m'indiquer par où commencer, je suis preneur.

Je te dirais franchement que je n'ai pas tout compris. Mais pour
information, j'arrive à déployer des applications github sur des
serveurs distant. Avec des clé ssh, pas de password ne transite sur le
réseau. Ensuite au niveau des fichiers comme database.yml, ils sont créé
sur les serveurs distant et linké à chaque nouvelle installation pour
ainsi le conserver. Donc, je ne vois pas le cas où tu dois montrer tes
login/pass

--
Cyril M.
http://blog.shingara.fr
Michel B. (Guest)
on 2009-02-13 14:13
(Received via mailing list)
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 ?

Michel B.
Cyril M. (Guest)
on 2009-02-13 15:29
(Received via mailing list)
Michel B. wrote:
> Capistrano en utilisant un système de contrôle de version parle
> 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-blo...)
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 M.
http://blog.shingara.fr
Michel B. (Guest)
on 2009-02-13 15:56
(Received via mailing list)
Donc si je récapitule :

   - Pour mes tweaks perso et les modifications nécessaires pour mon
   hébergeur j'ai intérêt à faire une branche sur le serveur publique
(pour ne
   pas polluer la branche master mais conserver la possiblité de merger
quand
   la branche master évollue sans perdre les petites modifs). Ca c'est
compris
   je vois comment faire.
   - Pour les fichiers de configuration où doit se trouver le dossier
   "/shared/" ? Dans ma copie locale de développement d'où je déploie ?
Sur le
   serveur de production, à la racine du projet ?
   - Les fichiers de Capistrano, ils doivent rester en local sur la
machine
   de développement et pas versionnés si j'ai bien compris (vu qu'ils
   contiennent un peu tous mes passwords ssh et github) ?

Sinon, merci pour ton blog, je suis en train de jeter un oeil. Merci
aussi
pour les fichiers d'exemple, je m'en inspirerais dès que j'aurais passé
l'étape du "j'ai besoin de beaucoups d'explications pour comprendre de
quoi
il s'agit".

Michel B.
Cyril M. (Guest)
on 2009-02-13 16:11
(Received via mailing list)
Michel B. wrote:
> Donc si je récapitule :
>
>     * Pour mes tweaks perso et les modifications nécessaires pour mon
>       hébergeur j'ai intérêt à faire une branche sur le serveur
>       publique (pour ne pas polluer la branche master mais conserver
>       la possiblité de merger quand la branche master évollue sans
>       perdre les petites modifs). Ca c'est compris je vois comment faire.
>
Oui il faut arriver à maintenir ses branches :)
>
>     * Pour les fichiers de configuration où doit se trouver le dossier
>       "/shared/" ? Dans ma copie locale de développement d'où je
>       déploie ? Sur le serveur de production, à la racine du projet ?
>
une arborescence de base capistrano est :
 - current
 - released
 - shared

current étant un lien symbolique sur un dossier de released
relesead est le dossier contenant les sources de ton appli avec le
"versionning" qui est en fait un dossier par timestamp
shared est le dossier ou tu mets ta configuration qui sera partagé entre
tous tes release du dossier released
>
>     * Les fichiers de Capistrano, ils doivent rester en local sur la
>       machine de développement et pas versionnés si j'ai bien compris
>       (vu qu'ils contiennent un peu tous mes passwords ssh et github) ?
>
le fichier deploy.rb ne contient normalement aucun mdp (vive la clé ssh)
sinon tout est versionné sur ton serveur. Ton dossier de développement,
n'a besoin que du deploy.rb qui finalement peux ne pas être versionné.
> Sinon, merci pour ton blog, je suis en train de jeter un oeil. Merci
> aussi pour les fichiers d'exemple, je m'en inspirerais dès que
> j'aurais passé l'étape du "j'ai besoin de beaucoups d'explications
> pour comprendre de quoi il s'agit".
>
Pas de quoi.

--
Cyril M.
http://blog.shingara.fr
Michel B. (Guest)
on 2009-02-13 16:18
(Received via mailing list)
Ok, je commence à mieux comprendre le tout, j'essaye de cette façon
ASAP.
Merci énormément pour les explications.

Michel B.
Jean-François Trân (Guest)
on 2009-02-13 16:29
(Received via mailing list)
Le 13 février 2009 14:56, Michel a écrit :

> Pour mes tweaks perso

Définir "tweaks perso" : rajout de contrôleur ? modif de modèle ? ...

> et les modifications nécessaires pour mon hébergeur
> j'ai intérêt à faire une branche

Pas forcément. ça dépend.

Quelques pistes : plugin - view_paths - themes - after task (dans
Capistrano)

    -- Jean-François.

--
http://twitter.com/underflow_
Michel B. (Guest)
on 2009-02-13 17:30
(Received via mailing list)
2009/2/13 Jean-François Trân <removed_email_address@domain.invalid>

>
> Le 13 février 2009 14:56, Michel a écrit :
>
> > Pour mes tweaks perso
>
> Définir "tweaks perso" : rajout de contrôleur ? modif de modèle ? ...
>

Plutôt ajout de CSS, modification du password admin dans le fichier de
configuration prévu à cet effet, ajout d'images de déco utilisées par
les
CSS perso, éventuellement modifs purement esthétiques dans une vue, etc.
Si
c'était du code ça irait par défaut dans une branche.


>
> > et les modifications nécessaires pour mon hébergeur
> > j'ai intérêt à faire une branche
>
> Pas forcément. ça dépend.
>
> Quelques pistes : plugin - view_paths - themes - after task (dans
> Capistrano)


Merci pour toutes les idées, je vais regarder déjà les "after tasks" si
la
méthode de Cyril ne suffit pas, le reste ne me semble pas vraiment
adapté
pour mon cas immédiat très précis (petite appli avec 1 contrôleur,
bientôt
2, peut-être 3 un jour si je vois un intérêt).

En fait, ce qui me manquait le plus c'était une explication humainement
compréhensible de ce que faisait Capistrano, parce que la littérature
massivement anglophone et jargonneuse que l'on trouve sur le sujet était
un
poil déroutante pour le novice que je ne me flatte pas d'être sur la
question.

Michel B.
Jean-François Trân (Guest)
on 2009-02-28 02:18
(Received via mailing list)
Le 13 février 2009 16:29, Michel a écrit :

> En fait, ce qui me manquait le plus c'était une explication
> humainement compréhensible de ce que faisait Capistrano,
> parce que la littérature massivement anglophone et jargonneuse
> que l'on trouve sur le sujet était un poil déroutante pour le
> novice que je ne me flatte pas d'être sur la
> question.

c'est un peu long, mais ça va te plaire, c'est en français :

http://www.pipoetmario.com/index.php?post/2008/06/...

   -- Jean-François.

--
http://twitter.com/underflow_
Michel B. (Guest)
on 2009-03-02 10:04
(Received via mailing list)
Merci, j'ai fini par réussir à déployer (peu de temps après mon
précédent
message sur ce thread). Je vais aussi jeter un oeil sur ce manuel "enfin
clair" bien nommé ^^

Michel B.


2009/2/28 Jean-François Trân <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.