Использование git-flow в многоэтапном развертывании - PullRequest
Новая
       19

Использование git-flow в многоэтапном развертывании

22 голосов
/ 31 августа 2011

Составление бланка с завершением моей схемы развертывания здесь.После публикации этого вопроса: Перенос рабочего сайта без VCS вообще на Git , у меня есть суть развертывания для локального репо.

Мой локальный сервер разработки имеет мерзавецрепозиторий на нем, на который я могу нажать, и он обновит внешнее рабочее дерево.

У меня есть репозиторий, настроенный с помощью git-flow, и вот как выглядит мой удаленный источник: 

$ 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 branches:
    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)

То, что я пытался сделать, было настроено 2 псевдо-среды.Один для постановки и один для производства.Я хочу, чтобы они вели себя следующим образом: 

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"

Таким образом, мы можем разрабатывать локально и переходить на наш маленький внутренний сервер разработки и иметь всю историю.Затем, когда мы готовы к постановке / производству, мы просто выталкиваем соответствующие ветви.

Я попытался создать голые репозитории с отдельными рабочими деревьями, как я делал с сервером разработки (см. Мою ссылку в началеpost), и просто сделал: 

git push staging develop
git push production master

А вот пульты, соответственно: 

$ 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)

Итак, теоретически мы можем использовать git-flow внутренне, отслеживать ветку разработкии вытолкнуть его для просмотра другими отделами / QA.Тогда мы сможем выполнить наше внутреннее освобождение, и перенести изменения в стадию, а затем просто перевести основную ветвь в производство.

Наверное, мой вопрос - правильно ли я поступаю?Я настоящий новичок, когда дело доходит до мерзавца и мерзавца.Я изучил все доступные ресурсы, и это лучшее, что я мог придумать.

Любые идеи от людей, которые используют git-flow в многоэтапном развертывании, будут высоко оценены.

Ответы [ 2 ]

5 голосов
/ 09 марта 2012

Вот что я в итоге сделал, это небольшое изменение того, что я предложил выше, и вытекает из другого вопроса, который я разместил здесь: Развертывание веток git

Один хук после полученияуправляйте ими всеми. #

Хук пост-приема смотрит на refname:

Если refname = "refs /head / master" (переход в ветку master): 

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

Затем я использую хук post-receive-email, поставляемый с git, для отправки небольшого электронного письма о коммите.В настоящее время разрабатывается API для нашего трекера, чтобы мы могли закрыть проблемы с коммитами и т. Д.

То же самое происходит, когда refname = "ref / head / development" (подталкивает к разработке):

BonusОчки

3 ветви - производство, разработка (подготовка) и ветка отслеживания проблем для небольших проектов.Иногда, однако, у нас есть более крупные проекты, которые требуют долгосрочной разработки и не могут мешать ежедневной разработке.

Вы можете изменить хук после получения, чтобы искать ссылки / заголовки /(.*?), Которые сработали бы, если бы вы сделали что-то вроде git push -u crazy-экспериментальный-long-term-branch

Это позволяет нам создавать долгосрочную ветку проекта, увеличивать ее с помощью -u и автоматически настраивать поддомен на crazy-experimental-long-term-branch.site.com с помощью простых сценариев.

Происходит день за днем, разрешение проблемы смещается и становится зеленым (с еженедельным запланированным слиянием с производством), и сумасшедшие экспериментальные долгосрочные ветви могут быть объединены, когда все будет готово.чувствительность Git Gods с этой стратегией развертывания, но мы успешно развертывали крупномасштабное приложение с этим методом в течение примерно 5 месяцев и, кроме случайного конфликта слияния, не имели никаких проблем.

Надеюсь, это полезно.

1 голос
/ 06 мая 2014

Если вы хотите развернуть только мастер, вы можете использовать следующий фрагмент: 

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