1

git 分岐モデルには、ライフタイムが無限の 2 つの分岐があるワークフローがあります。developwheremasterは、運用準備完了状態と、最新の開発変更が配信されmasterた状態を反映しています。develop

developからに移行するには、新しい製品リリースの準備をサポートmasterする中間状態を通過します。これらの準備 (シェル スクリプトまたは手動での変更) の後、リリース ブランチを master にマージし、タグを付けて、運用環境にプッシュします。release branch

この時点では、運用のみの変更が行われます。たとえば、外部サービスは運用環境とステージング環境で異なる URL を持つためです。

にマージし直さない限り、今masterは常に先を行っています。developdevelop

私が(a)それを行うと、リリースブランチで行われたすべての本番のみの変更が開発にマージされます

私が (b)そうしないと、私のマスターは常に前後にdevelopあり、マスターから分岐するホットフィックスの場合、修正develop後にとにかくすべてをマージしてしまいます。

このモデルを使用して、開発ブランチから本番環境の変更のみを遠ざけるようにする最善の方法は何ですか?

4

1 に答える 1

1

これは、git に関する質問というよりも、構成管理に関する質問です。この問題は git に固有のものではなく、すべてのバージョン管理システムの問題です。ベスト プラクティスは、運用のみの変更をすべて排除するか、少なくとも最小限に抑えることです。

これは、いくつかの方法で行うことができます。

  • 構成値をデータベースに入れます。これは、単純な構成を変更するためにデータベースを変更する必要があることに悩まされるまで機能します

  • 構成をファイルに入れ、本番環境で変更される単一の変数に基づいて if ステートメントを使用します。例えば：

    if ( production ) 値 = キー
    else 値 = otherkey

    基本的にテストされていないコードがあるため、これも素晴らしいことではありません。

  • config を環境変数に入れます。これはかなりうまく機能しますが、展開プロセスがそれらをインスタンス化して設定することを確認することをお勧めします。

  • ただし、実際の最新技術を取得したい場合は、構成を独自のリポジトリに配置し、パペットやシェフなどの自動化ツールを使用します

于 2013-11-05T03:48:19.603 に答える