Utilisation de git-flow dans un deployment en plusieurs étapes

Dessiner un blanc avec la finalisation de mon schéma de deployment ici. Après avoir posté cette question: Migrer un site de production sans aucun VCS vers Git , j'ai l'essentiel de déployer dans un repo local.

Mon server de développement local dispose d'un référentiel git-flow sur lequel je peux pousser et mettra à jour un workstree externe.

J'ai mon repo mis en place avec git-flow et voici à quoi ressemble ma télécommand d'origine:

$ git remote show origin * remote origin Fetch URL: ssh://user@host/var/git/dev/repo.git Push URL: ssh://user@host/var/git/dev/repo.git HEAD branch (remote HEAD is ambiguous, may be one of the following): develop master Remote twigs: develop tracked master tracked Local branch configured for 'git pull': master merges with remote master Local refs configured for 'git push': develop pushes to develop (up to date) master pushes to master (up to date) 

Ce que j'ai essayé de faire, c'était de créer 2 pseudo-environnements. Un pour la mise en scène et un pour la production. Je veux les faire se comporter comme suit:

 git push staging #pushes to remote staging repo with a post-receive hook "git checkout develop -f" git push production #pushes to remote production repo with a post-receive hook "git checkout master -f" 

De cette façon, nous pouvons développer localement et pousser à notre petit server de développement interne et avoir toute l'histoire. Ensuite, quand nous sums clairs pour la mise en scène / production, nous poussons simplement les twigs appropriées.

J'ai essayé de créer des repos nus avec des trees de travail séparés comme je l'ai fait avec le server de développement (voir mon lien au début de la publication), et j'ai simplement fait:

 git push staging develop git push production master 

Et voici les télécommands, respectivement:

 $ git remote show staging * remote staging Fetch URL: ssh://user@host/var/git/dev/staging.git Push URL: ssh://user@host/var/git/dev/staging.git HEAD branch: develop Remote branch: develop tracked Local ref configured for 'git push': develop pushes to develop (up to date) $ git remote show production * remote produdction Fetch URL: ssh://user@host/var/git/dev/production.git Push URL: ssh://user@host/var/git/dev/production.git HEAD branch: master Remote branch: master tracked Local ref configured for 'git push': master pushes to master (up to date) 

Donc, en théorie, nous pouvons utiliser git-flow en interne, suivre la twig de développement et la pousser vers d'autres départements pour voir / QA. Ensuite, nous pouvons faire notre libération interne, et pousser les changements à la mise en scène, puis pousser simplement la twig principale à la production.

Je suppose que ma question est – est-ce que j'y vais de la bonne façon? Je suis un vrai novice quand il s'agit de git et git-flow. J'ai examiné toutes les ressources disponibles et c'est le meilleur que j'ai pu find jusqu'à présent.

Toute idée de ceux qui utilisent git-flow dans un deployment en plusieurs étapes serait grandement appréciée.

Solutions Collecting From Web of "Utilisation de git-flow dans un deployment en plusieurs étapes"

Voici ce que j'ai fini par faire, c'est une légère variation de ce que j'ai proposé ci-dessus et provient d'une autre question que j'ai posté ici: Déployer des twigs git

Un hook post-réception pour les gouverner tous. #

Le crochet de réception de message regarde le refname:

Si le refname = "refs / heads / master" (pousser à la twig master):

 echo "Updating production document root..." GIT_WORK_TREE=/data/hosts/production/web/ git checkout -f master echo "Production document root updated" 

Ensuite, j'utilise le hook post-receive-email fourni avec git pour envoyer un joli petit email sur le commit. Nous développons actuellement une API pour notre outil de suivi des problèmes afin que nous puissions résoudre les problèmes avec les validations, etc.

La même chose se produit quand refname = "ref / heads / develop" (pousser à développer):

Points bonus

3 twigs: production, développement (mise en scène) et une twig de suivi des problèmes pour les projets de petite taille. Parfois, cependant, nous avons des projets plus importants qui nécessitent des dev à long terme et ne peuvent pas empêcher le développement quotidien.

Vous pouvez modifier le hook post-réception pour searchr refs / heads /(.*?), Qui se triggersrait si vous faisiez quelque chose comme git push -u crazy-experimental-long terme twig

Cela nous permet de créer une twig de projet à long terme, de la pousser avec -u, et d'avoir un sous-domaine configuré automatiquement à crazy-experimental-long-term-branch.site.com avec un script simple.

Le dev de jour en jour se produit, lance la résolution et obtient le feu vert (avec des fusions hebdomadaires programmées à la production), et des twigs folles expérimentales à long terme peuvent être fusionnées lorsqu'elles sont prêtes.

Je suis sûr que je suis offenser les sensibilités des dieux Git avec cette stratégie de deployment, mais nous avons déployé avec succès une application à grande échelle avec cette méthode pendant environ 5 mois et en dehors du conflit occasionnel de fusion, n'ont pas eu problèmes.

J'espère que c'est utile.

Si vous souhaitez uniquement déployer le maître, vous pouvez utiliser l'extrait suivant:

 read oldrev newrev refname branch=$(git rev-parse --symbolic --abbrev-ref $refname) if [ "$branch" = "master" ]; then echo "Deploying new master" GIT_WORK_TREE="$DEPLOYDIR" git checkout -f master echo "Finished." else echo " No commit to master. Deploying nothing." fi