Git Flowを使用する場合、どのアーティファクトを本番環境にデプロイする必要がありますか？
Git Flowを使用するときに、次の一連のコミットがあるとします。
次のリリースには新機能は含まれないと述べ、リリースブランチ（D）を作成しました。 QAがテストを開始し、バグを発見しました。これを修正しました（E）。
QAがテストを終了したため、リリースを完了し、マスターにマージして、マスターのバージョンを開発してタグを付けます（F）。
私たちのCIリリースプロセスは、マスターで作成された新しいタグを監視し、コードをビルドしてアーティファクトを生成します。
問題は、コードは同じかもしれないが、EとFで生成されるアーティファクトが100％バイナリーであるとは限らないということです。ビルドの一部の側面は、同じ方法で再現できない場合があります。たとえば、HTTP経由で依存関係を提供するためにパッケージマネージャーに依存している場合、両方のビルドで同じように動作する外部システムのなすがままです。ほとんどの場合そうなると思いますが、保証はありません。
どのアーティファクトを製品にデプロイする必要がありますか？
Eからアーティファクトをデプロイする場合、マスターブランチにv1のタグを付けたのは少し変ではないですか？私は一種の遡及的にコミットをリリースバージョンとして指定する必要があります。
Fからアーティファクトを展開すると、Eとは異なる方法でアーティファクトが壊れる（小さな）危険があります。 QAはFを再テストできますが、それはやや無駄なサイクルであり、重大なバグを見つけた場合はどうなりますか？それを修正するには、2番目のリリースが必要です。v1.0.0は使用されなくなり、無意味になります。
構築するアーティファクトに、ビルド時にタグの有無に関連する情報が含まれていない場合、アーティファクトを再構築せずに済む方法があります。
Masterブランチが早送りマージのみを受け入れるように環境を調整すると、「commit F」と「commit E」が実際には1つの同じコミット（同じコミットハッシュ）であることが保証されます。その場合、タグは実際には「コミットE」に配置され、QAが承認したものとまったく同じ成果物をバージョン1.0.0としてリリースできます。
これが機能するのは、早送りコミットでは新しいコミットは作成されず、ターゲットブランチの先頭のマーカーのみが移動されるためです。高速転送マージは、リリースブランチにも存在しないコミットがマスターにない場合にのみ可能です。
問題は、コードは同じかもしれないが、EとFで生成されるアーティファクトが100％バイナリーであるとは限らないということです。ビルドの一部の側面は、同じ方法で再現できない場合があります。
これはGitFlowの問題ではなく、ビルドプロセスの問題です
ビルドプロセスが同じソースコードで同じ結果を生成しない場合、それは役に立たないプロセスです。ビルドプロセスを確定する必要があります。 GitFlowは、ビルドを確定的にすることではなく、ソースコードを管理することを目的としています。 使用するソース管理戦略に関係なく、ビルドを確定する必要があります。
あなたの例に取り組むには：
たとえば、HTTP経由で依存関係を提供するためにパッケージマネージャーに依存している場合、両方のビルドで同じように動作する外部システムのなすがままです。ほとんどの場合そうなると思いますが、保証はありません。
リリースビルドを制御していないシステムに依存しないでください
開発およびビルドプロセスの一部としてパッケージマネージャーを使用することは完全に問題ありません。しかし、完全に同じである必要があるリリースビルドを作成する場合は、驚かれるような動作をするものに依存するべきではありません。次の方法で、パッケージマネージャからの驚きを排除できます。
依存関係のバージョンを固定する。使用する価値のあるパッケージマネージャであれば、これを行うことができます。あなたは間違いなくこれをすでにやっているはずです。
リリースするソフトウェアが依存する、フェッチされた依存アーティファクトのキャッシュ。そうすれば、上流のシステムで何が発生しても問題はありません。必要なときに、常に正しい依存アーティファクトがあります。使用しているアーティファクトの種類とパッケージマネージャーに応じて、この種の機能を提供する多くのソリューションがあります。
編集：コメントに基づいて、確定的なビルドプロセスが望ましい、または可能である理由については、多くの混乱があります。この混乱に追加されるのは、GitFlow自体の追加の些細な詳細です。これは、問題のactual問題に対処することには実際にはまったく重要ではありません。ビルドプロセスから実際にです。
確定的なビルドプロセスが必要です
同じソースコードから同じ結果を生成するビルドプロセスが必要な理由は、ビルドプロセス中に発生する可能性のあるエラーのクラス全体または意図的なセキュリティの脆弱性を排除するためです。プロセスが常に同じソースコードから同じバイナリを生成することが確実にわかっている場合は、ソフトウェアを構築する他の関係者（チームの他の開発者とQA部門、またはオープンソースの世界では、他の開発者がインターネット）は、ビルド自体が「正しい」かどうかを判断し、より大きな問題を示している可能性が高いため、すべての逸脱を精査する必要があることを知っています。
質問の例に関連して、コミットEとコミットFに同じソースコードが含まれていると仮定すると、ビルドの結果がコミットEとコミットFのどちらであるかは関係ありません。同一であること。プロセスへの入力は同一であるため、プロセスからの出力は同一である必要があります。そうでない場合、非常に大きな問題が発生します。コミットEのビルドとコミットFのビルドが同じでない場合、時間の経過に伴うコミットEとコミットFの複数のビルドも同じにならないためです。
リビジョン管理システムを持つことの全体的なポイントは、履歴内の特定のインスタンスの間に存在していた結果のソフトウェアの状態が保持されることを保証するためです。ビルドシステムを持つことの全体は、ソフトウェアが一貫したエラーのない方法でビルドされることを確認することです。これが実際の動作と異なる場合は、これらのツールがもたらすはずの安定性の利点をまったく得られないように、多くの追加作業を行っています。
「わかりました。どのコミットをリリースすればよいですか？」
それらが実際に同じソースコードである場合、どのコミットをリリースするかは関係ありません。明らかに、テスト済みのビルドのみをリリースする必要があります。テストした顧客にビルドを常にリリースする必要があります。しかし、それがコミットEであるかコミットFであるかは問題ではありません。あなたのコンパイラはコミットが何であるかさえ知りません。 ビルドプロセスへのinputであるコミットに焦点を当てると、ビルドプロセスの出力は。
"しかし、再現可能なビルドは不可能です"
多くの主要なソフトウェア会社、セキュリティ専門家、そしてDebianプロジェクトは、それについてかなり強くあなたに反対するでしょう。再現可能なビルドを作成する方法の詳細については、こちらをご覧ください。 https://reproducible-builds.org/
「なぜ同じコードを2回ビルドしたいのですか？」
同じコードを2度作成したい理由はたくさんありますが、以下にすべての理由を挙げます。
- 場合によっては、顧客が失い、CIシステムがコピーを保持しなくなったリリースビルドを置き換える必要があります。
- 他の人はソフトウェアを自分で構築したいと思うかもしれません。チームの他の開発者、オープンソースコミュニティ、またはソースコードの代金を支払った顧客。ビルドを再現できない場合、どのようにしてビルドが正しく行われたかを知ることができますか？
- ビルドシステムが壊れているか、別のマシンで再作成する必要があるとします。新しいシステムが正しく機能していることをどのように検証しますか？
- アプリケーションのアーキテクチャによっては、ビルドプロセスにモジュールのコレクションを個別にコンパイルして、それをアセンブルして、デプロイする最終的なアーティファクトを形成する場合があります。変更が行われる前のコミットの数に関係なく、変更していないモジュールをまったく同じようにビルドすることをお勧めします（変更しない場合は、プロセスを高速化するためにこれらのモジュールをどこかにキャッシュします）。
- さらに良いことに、ソースコードが変更されなくてもモジュールが変更されないことが確実にわかっている場合は、これらのモジュールのビルドを完全にスキップして、ビルドプロセスを高速化できます。
- ソフトウェアがクロスプラットフォームである場合、同じソースコードから各プラットフォーム用のビルドがある可能性があります。
「しかし、GitFlowが完全に無意味であることを理解する方法で、マスターから2番目のビルドを作成します！」
ここでは、マスターから2番目のビルドを行うべきか、GitFlowに従うべきだとは言いませんでしたが、ロボットのような献身でそれを理解しています。答えの最初の言葉は「これはGitFlowの問題ではない」です。これは、コミットが作成されることのトリビアは、同じ入力であるという事実を変更しないためですビルドプロセスの結果は同じoutput。になるはずです