Salut,
Ici le comportement est similaire : on a des branches
dev/recette-XXX/master qui sont buildées et testées à chaque commit par
jenkins et déployées par fabric à chaque build+tests OK.
La branche master se déploie sur la preprod toute seul donc ; et pour
certains projets même (pas les plus critiques) en prod dans la foulée si
le deploy s'est bien passé.
Depuis qu'on a ce fonctionnement on est plutôt robuste sans être
contraignant : les devs savent que X minutes après le commit sur un
projet et une branche donnée, ça sera déployé sur l'environnement
d'intégration correspondant.
Pour résumer on ne déploie pas directement en post-hook git mais après
build+test sur jenkins qui lui est post-hooké au git.
Les reverts sont aussi possibles immédiatement car tout nos builds
fabriquent un livrable .tgz qui est archivé sur le serveur qui gère les
déploiements.
A+
Valentin
On 16/05/2013 00:55, seb astien wrote:
Salut,
Les devs ont des branches qu'ils mergent régulièrement avec master, on
tag lorsqu'on souhaite déployer et que ça passe les tests.
> Je faisais cela à partir d'un svn, je passais par un script que les dev
> lançait avec le tag svn qui doit être livré, rollback au tag précédent
> en cas de soucis et surtout plein d'actions annexe comme re minifier /
> combiner les js et css, faire des actions en bases, ...
On déploie avec un fabric qui git checkout du tag sur plusieurs vms,
migrate, css... Hook new relic
Facile de revert, et garantie que le code déployé est le même partout.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
