24

在这里完成我的部署方案时画一个空白。发布此问题后：将完全没有 VCS 的生产站点迁移到 Git后，我​​已经掌握了部署到本地存储库的要点。

我的本地开发服务器上有一个 git-flow 存储库，我可以推送到它，它将更新外部工作树。

我用 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"

这样，我们可以在本地开发并推送到我们的小型内部开发服务器并拥有所有历史记录。然后，当我们明确分期/生产时，我们只需推出适当的分支。

我尝试使用单独的工作树创建裸仓库，就像我对开发服务器所做的那样（请参阅帖子开头的链接），并且简单地做了：

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，跟踪develop分支，推送出去给其他部门查看/QA。然后我们可以在内部进行发布，并将更改推送到 staging，然后简单地将 master 分支推送到生产环境。

我想我的问题是——我这样做的方式是否正确？在 git 和 git-flow 方面，我是一个真正的新手。我已经仔细研究了所有可用的资源，这是迄今为止我能想到的最好的。

非常感谢在多阶段部署中使用 git-flow 的人们提供的任何见解。

4

2 回答 2

5

这是我最终做的，这是我上面提出的略有不同，源于我在这里发布的另一个问题：部署 git 分支

一个 post-receive 钩子来统治他们。#

Post receive 钩子查看 refname：

如果 refname = "refs/heads/master"（推送到 master 分支）：

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

然后我使用 git 附带的 post-receive-email 钩子发送一封关于提交的漂亮小电子邮件。目前正在为我们的问题跟踪器开发一个 API，以便我们可以通过提交等关闭问题。

当 refname = "ref/heads/develop" （推动开发）时也会发生同样的情况：

奖励积分

3 个分支 - 生产、开发（登台）和小型项目的问题跟踪器分支。但有时，我们有较大的项目需要长期开发，并且不能妨碍日常开发。

您可以修改 post-receive 挂钩以查找 refs/heads/(.*?)，如果您执行 git push -u crazy-experimental-long-term-branch 之类的操作，它将触发

这让我们可以创建一个长期项目分支，使用 -u 将其推送，并通过一些简单的脚本在 crazy-experimental-long-term-branch.site.com 上自动设置一个子域。

日常开发发生，问题解决滚动并获得批准（每周计划合并到生产），并且可以在准备好时合并疯狂的实验性长期分支。

我确信我用这种部署策略冒犯了 Git 神的敏感性，但是我们已经用这种方法成功部署了大约 5 个月的大型应用程序，除了偶尔的合并冲突之外，还没有任何问题。

希望这会有所帮助。

于 2012-03-09T17:15:24.607 回答
1

如果您只想部署主服务器，可以使用以下代码段：

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
于 2014-05-06T13:19:04.173 回答