Déployer d'un répository local avec Cap istrano

Community FR
1

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.

2

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.

3

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.

4

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.

5

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-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 M.

6

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 :slight_smile:

* 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.

7

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_

8

Ok, je commence à mieux comprendre le tout, j’essaye de cette façon
ASAP.
Merci énormément pour les explications.

Michel B.

9

2009/2/13 Jean-François Trân [email protected]

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.

10

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 [email protected]

11

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 :

– Jean-François.

–
http://twitter.com/underflow_