Vu sur la mailing-list capistrano :
http://blog.innerewut.de/webistrano/
C’est intéressant ça. Si ça peut rendre Capistrano compréhensible
j’achète
^^
On 8/29/07, Jérémy DIERX [email protected] wrote:
Vu sur la mailing-list capistrano :
http://blog.innerewut.de/webistrano/
–
Michel B.
Thibaut Barrère wrote:
En parlant de Capistrano (ou plutôt d’une alternative) - quelqu’un a
testé Vlad the deployer ?
Hors sujet :
avec un nom pareil j’ai peur de faire mal à mon serveur 
Sinon, de manière générale je préfère utiliser le gestionnaire de paquet
de ma distrib plutôt qu’un capistrano ou vlad. Peut-être une question
d’habitude, mais je ne vois pas trop comment gérer les dépendences et
faciliter la gestion de version en production : pour la maintenance,
cela me semble plus facile d’avoir à faire un checkout du
TAG-ma_version_en_prod pour pouvoir reproduire le bug que de noter
quelque part le tag ou la révision poussé par capistrano ou vlad en
production) avec un capistrano-like et aller le chercher en espérant que
le dernier qui a poussé la version actuelle n’a pas oublié de mettre à
jour le fichier (ou est-ce qu’il y a quelque-chose dans cap/vlad pour
automatiser ce genre de choses).
C’est déjà pénible lorsqu’on a un serveur en prod, mais si en plus on
instancie son application à plusieurs endroits sans forcément
synchroniser les versions, là ça devient ingérable sans ce suivi de
version en prod.
Lionel
En parlant de Capistrano (ou plutôt d’une alternative) - quelqu’un a
testé Vlad the deployer ?
http://rubyhitsquad.com/Vlad_the_Deployer.html
– Thibaut
Lionel:
Thibaut Barrère wrote:
En parlant de Capistrano (ou plutôt d’une alternative) - quelqu’un a
testé Vlad the deployer ?Hors sujet :
avec un nom pareil j’ai peur de faire mal à mon serveur
Ouh, il y a un projet (également de seattle.rb) qui a un nom pire que
ça !
Sinon, de manière générale je préfère utiliser le gestionnaire
de paquet de ma distrib plutôt qu’un capistrano ou vlad.
genre, tu crées un paquet .deb de ton appli ?
Peut-être une question d’habitude, mais je ne vois pas trop
comment gérer les dépendences et faciliter la gestion de
version en production : pour la maintenance,
cela me semble plus facile d’avoir à faire un checkout du
TAG-ma_version_en_prod pour pouvoir reproduire le bug que de noter
quelque part le tag ou la révision poussé par capistrano ou vlad en
production) avec un capistrano-like
C’est possible de déployer une appli depuis une branche ou un tag (svn)
et non depuis le tronc. Ou même depuis un tarball.
et aller le chercher en espérant que
le dernier qui a poussé la version actuelle n’a pas oublié de mettre à
jour le fichier (ou est-ce qu’il y a quelque-chose dans cap/vlad pour
automatiser ce genre de choses).
“it’s all about automation” comme dirait le danois.
avec la stratégie par défaut, un fichier REVISION est
crééautomatiquement. On peut faire de même si on déploie depuis un
tag svn. De plus il y a un système de callbacks avec les tâches.
C’est déjà pénible lorsqu’on a un serveur en prod, mais si en plus on
instancie son application à plusieurs endroits
déployer sur plusieurs serveurs c’est le domaine de prédilection de
Capistrano…
sans forcément synchroniser les versions,
là ça devient ingérable sans ce suivi de
version en prod.
De plus on peut créer des fichiers de config à la volée (j’ai l’impression
d’être un représentant de commerce là), automatiser le lancement
de serveurs ou démons, du build automatique (vmbuilder, railsmachine,
deprec…)
– Jean-François.
–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)
Jean-François Trân wrote:
Sinon, de manière générale je préfère utiliser le gestionnaire
de paquet de ma distrib plutôt qu’un capistrano ou vlad.genre, tu crées un paquet .deb de ton appli ?
A une époque c’était des RPMs, mais je suis passé aux ebuilds avant de
passer à Rails
et non depuis le tronc. Ou même depuis un tarball.
Hum, intéressant !
et aller le chercher en espérant que
le dernier qui a poussé la version actuelle n’a pas oublié de mettre à
jour le fichier (ou est-ce qu’il y a quelque-chose dans cap/vlad pour
automatiser ce genre de choses).“it’s all about automation” comme dirait le danois.
avec la stratégie par défaut, un fichier REVISION est créé
automatiquement. On peut faire de même si on déploie depuis un
tag svn. De plus il y a un système de callbacks avec les tâches.
Ok, ça me parait bien tout ça.
C’est déjà pénible lorsqu’on a un serveur en prod, mais si en plus on
instancie son application à plusieurs endroitsdéployer sur plusieurs serveurs c’est le domaine de prédilection de
Capistrano…
Oui, mais là je pensais surtout à maintenir la même application à
plusieurs endroits sans pour autant avoir la même version.
– Jean-François
N’en jette plus
pose la question de savoir si ça vaut le coup que je gère les
dépendances à l’aide du gestionnaire de paquets. Surtout qu’on peut
imaginer que je les gère de manière limitée par Capistrano ou Vlad.
Lionel
Lionel :
[…]
C’est possible de déployer une appli depuis une branche ou un tag (svn)
et non depuis le tronc. Ou même depuis un tarball.Hum, intéressant !
Précision : quand je disais “depuis un tarball”, je voulais dire qu’au
lieu que les serveurs fassent chacun un export/checkout, celui-ci était
fait localement par Cap, un tarball temporaire était créé localement et
envoyé
aux serveurs par Cap.
Si le tarball existe déjà, cela nécessite d’écrire sa propre stratégie et
peut être aussi sa propre recette.(par exemple écrire un fichier TAG
au lieu de REVISION, tout en gardant les noms de répertoires timestampés)
[…]
N’en jette plus
pose la question de savoir si ça vaut le coup que je gère les
dépendances à l’aide du gestionnaire de paquets. Surtout qu’on peut
imaginer que je les gère de manière limitée par Capistrano ou Vlad.
Le pb avec la gestion de paquets (non rubygems :), c’est que c’est
difficile (voire impossible) d’avoir plusieurs versions (dans le sens :
plusieurs versions des sources) de son appli sur le serveur.
çacomplique le rollback.
Sinon pour la vérification des dépendances, ceci est intéressant à
lire :
http://atnan.com/2007/1/11/using-capistrano-to-check-for-deployment-dependancies
– Jean-François.
–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)
On 8/30/07, Lionel B. [email protected] wrote:
Toi tu ne connais pas Portage…
Oui portage c’est le truc qui te fait patienter des heures avant de
pouvoir travailler, le truc qui fait tourner ton pc pendant des heures
contribuant à la pollution de l’environnement, le truc qui fait croire
à ses utilisateurs qu’ils sont des gourous unix parce qu’ils ont tapé
trois lignes de commandes et utilisés fdisk, le truc qui fait croire
que leur pc tournera plus vite parcequ’ils ont tout compiler à la
main. Le truc que même linus et rms n’utilisent pas :-))
Jean-François Trân wrote:
Toi tu ne connais pas Portage…
Lionel
Patrick A. wrote:
que leur pc tournera plus vite parcequ’ils ont tout compiler à la
main. Le truc que même linus et rms n’utilisent pas :-))
En supposant que ces remarques soient objectives et relatives à une
expérience réelle de la distribution qu’on pourrait prendre au sérieux,
puis-je respectueusement m’enquérir du rapport avec le sujet de notre
discussion, à savoir la possibilité de supporter facilement plusieurs
versions d’un même logiciel ?
Lionel, tentant l’esquive de Troll
On 8/30/07, Lionel B. [email protected] wrote:
à savoir la possibilité de supporter facilement plusieurs
versions d’un même logiciel ?
Si c’est une appli rails, je pense que ce qui a de mieux c’est gem
comme tu dois déjà savoir. Pour les autre logiciel, le plus important
c’est d’offrir un tarball que les utilisateurs peuvent compiler, ce
qui permet aussi aux distributions de packager ton logiciel si elles
sont intéressées. Si aucune distribution n’est intéressée, tu peux
très bien le packager toi même pour plusieurs distro avec buildbot
(google…).
Enfin ça pour c’est pour le packaging, pour la gestion de version
t’utilises tout simplement ton SCM favori (svn, git, hg etc) et quand
tu veut faire une release tu tag la branche en question avec le nom de
ta release ou version. Comme ça ça te permet de naviguer entre tes
différentes releases facilement. Et pour le déploiement des
différentes versions, on a capistrano et ses recettes et apparemment
vlad the dev qui a l’air super cool.