一个post-receive钩子来统治它们。＃

Question

在此处完成我的部署方案，绘制一个空白。在发布这个问题之后：Migrating a production site with no VCS at all to Git，我已经掌握了部署到本地仓库的要点。

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

我用git-flow设置了我的repo，这就是我的原始遥控器的样子：

$ 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，跟踪开发分支并推送出去供其他部门查看/ QA。然后我们可以在内部进行发布，并将更改推送到暂存，然后简单地将主分支推送到生产阶段。

我想我的问题是 - 我是否以正确的方式进行此操作？对于git和git-flow，我是一个真正的新手。我已经仔细研究了所有可用的资源，这是迄今为止我能想到的最好的资源。

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

Answer 1

这是我最终做的事情，这是我上面提出的一个细微变化，源于我在这里发布的另一个问题：Deploy git branches

一个post-receive钩子来统治它们。＃

post receive hook查看refname：

如果refname =“refs / heads / 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 Gods的敏感性，但是我们已经用这种方法成功地部署了大规模的应用程序大约5个月，除了偶尔的合并冲突，避风港'有任何问题。

希望这有用。

Answer 2

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

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

在多阶段部署中使用git-flow

2 个答案:

一个post-receive钩子来统治它们。＃

奖励积分