28

Git + Heroku (Ruby on Rails) で使用するのに適した展開戦略は何ですか?

現在、オリジン Git リポジトリで作業する方法: すべての機能 (または「ストーリー」) は、最初にブランチとしてチェックアウトされ、次にマスターとマージされ、オリジンにプッシュされます。

origin/master にプッシュされたものはすべて、新しい Rails コードをステージング エリア (単純な Rails Web サーバー) にプルするスクリプトをトリガーします。

新しい製品バージョンを Heroku にプッシュするときが来たら、新しいブランチ (production_version_121 などと呼ばれる) を作成し、それを何らかの方法で Heroku にプッシュする必要がありますか?

理想的には、以前の開発バージョンからどの機能を本番ブランチに含めるかを選択して選択し、テストして、Heroku にプッシュしたいと考えています。

たとえば、すべての最新コードを本番環境にプッシュしたくない場合があります。もっとデバッグが必要な実験的な機能「b」を含めずに、私が取り組んできた機能「a」と機能「c」の両方を何らかの形で本番環境にマージしたいと思うかもしれません。

注意: 最初は Capistrano を避けて、今のところ手動で動作するようにします。

何かご意見は？ベストプラクティス？

4

3 に答える 3

16

Vincent Driessen のA success Git branching modelを読んで以来、私は夢中になっています。私の会社全体 (私たち 8 人) は現在、このモデルを標準化しており、私が相談した他のいくつかの場所も同様に使用し始めています。

私がそれを見せたほとんどの人は、すでに似たようなことをしていて、非常に簡単に適応できると言っています.

簡単に言えば、永続的な 2 つのブランチ (マスターと開発) があります。ほとんどの場合、develop からブランチを作成し、develop にマージするだけです。製品版のリリースやホットフィックスを行うようになると、状況はもう少し複雑になりますが、投稿を数回読んだ後、それは染み込んでしまいます。

あなたを助けるために、git-flowと呼ばれるコマンドラインツールさえあります。

于 2010-10-26T15:12:11.000 に答える
7

これにはさまざまな方法があり、好みによって異なります。

頭のてっぺんから考えられる戦略を 1 つ紹介します。master を使用する自動化されたステージングのセットアップが既にある場合は、「運用」ブランチを作成することをお勧めします。修正/機能を本番環境に昇格させたい場合は、トピック ブランチを「本番」ブランチにマージするだけです。

git checkout production
git pull . my-topic-branch
(resolve any conflicts)

そのコードを本番サーバーに実際にプッシュする準備ができたら、一意の名前 (おそらくタイムスタンプ付き) を使用してブランチにタグを付ける必要があります。次に、本番ブランチを Heroku にプッシュするだけです。

git checkout production
git tag release-200910201249

一貫した命名スキームを使用することが重要であるため、スクリプトまたは git エイリアスを作成してタイムスタンプのタグ付けを自動化することをお勧めします。私は次のようなものを使用します：

git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`'

git dtagこれにより、タイムスタンプでリリースにタグを付けたいときにタイプするだけで済みます。

git tagを使用してタグを表示し、 を使用してタグを表示できますgit show release-1234。タグの詳細については、 を実行してgit help tagください。タグ付けに関するこのGithub ガイドも役立つ場合があります。また、他の人のワークフローを読んで（ここに素晴らしい記事があります）、自分に合ったものを選んで選択することをお勧めします.

于 2009-10-07T18:52:09.090 に答える