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つの疑似環境を設定することでした。1つはステージング用で、もう1つは本番用です。私はそれらを次のように動作させたいです:

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を使用している人々からの洞察をいただければ幸いです。

4

2 に答える 2

5

これが私がやったことです。これは私が上で提案したもののわずかなバリエーションであり、私がここに投稿した別の質問から生じています:gitブランチをデプロイする

それらすべてを支配するための1つの受信後フック。

ポスト受信フックは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 / development"(開発をプッシュ)の場合も同じことが起こります。

ボーナスポイント

3つのブランチ-生産、開発(ステージング)、および小規模プロジェクト用の課題追跡ブランチ。ただし、長期的な開発を必要とし、日々の開発の邪魔にならない大規模なプロジェクトがある場合もあります。

受信後のフックを変更して、refs / heads /(。*?)を探すことができます。これは、git push-ucrazy-experimental-long-term-branchのようなことをした場合に起動します。

これにより、長期的なプロジェクトブランチを作成し、-uを使用してプッシュアップし、簡単なスクリプトを使用してサブドメインをcrazy-experimental-long-term-branch.site.comに自動的に設定できます。

日々の開発が行われ、問題の解決がロールバックされて青信号になり(毎週スケジュールされた本番環境へのマージで)、準備ができたらクレイジーな実験的な長期ブランチをマージできます。

このデプロイ戦略でGitGodsの感性を傷つけていると確信していますが、この方法で大規模なアプリケーションを約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 に答える