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/