4

設定

master一般的なセットアップには、ブランチ、stage(プレリリース) ブランチ、およびブランチが含まれるいくつかの gitlab リポジトリがありますdev。

3 つのブランチすべてでプッシュ権限が無効になっています。

devワークフローは、すべてのホット フィックス、バグ修正、および機能のためにブランチからフォークすることです。リリースに満足したら、マージリクエストを に送信しdevます。最終的に、内部で安定したビルドの準備が整うとdev、; stageブランチに対してマージリクエストが送信されます。最後に、プレリリースに満足したら、masterブランチのマージ要求を送信します。

ファイルの自動生成を使用して、masterおよびstageブランチからテスト、ビルド、および展開が自動的に実行されるように、CI/CD を構成しました。ブランチは UAT s3 バケットにデプロイされ、本番 s3 バケットにデプロイされます。CHANGELOG.mdstagemaster

デプロイはSemantic Versioning 2.0.0、バージョンのバンプ、変更ログの生成、およびデプロイを担当する によって処理されます。

モノレポであることを除いて、上記と同様のセットアップを使用しているため、の動作をレプリケートLernaするために発行 (デプロイ) を処理するために使用しています。monorepo 内で独立したバージョン管理を使用しています。{"conventionalCommits": true}Semantic Versioning 2.0.0

と の両方のSemantic Versioning 2.0.0設定により、ブランチは常にとのブランチの後ろまたは同じになるようにLerna強制されます。ブランチは、カスケード効果のようなもので、常にブランチの後ろまたは同じになるようにします。masterstagedevstagedev

dev>= stage>=master

問題

と の両方Lerna PublishでSemantic Versioning、公開/展開時にファイルにいくつかの変更を加えます。これらの変更には、ファイルの更新とCHANGELOG.mdファイル内のバージョンのバンプが含まれpackage.jsonます。

Lerna とセマンティック バージョニングはどちらも、最終的にこれらの変更を、CI/CD を介して実行元のブランチにプッシュします。

devこれが意味することは、 からにマージするstageと、セマンティック バージョニングまたは Lerna Publish の実行によって、ステージのバージョン番号が増加し、新しい変更ログがステージにプッシュされるということです。これにより、stageブランチがブランチよりも先になり、ブランチdevからの将来のすべてのフォークがdevブランチから切り離されます。stageつまり、次にマージするときにdev、意図されているようstageな単純なマージにはなりません。fast-forwardマージは競合に遭遇する可能性が高く、将来のマージが妨げられるか、CI/CD が失敗する可能性があります。

私の回避策

セマンティック バージョニングの場合:

  • プッシュ機能を無効にして、新しく変更されたファイルがコミットおよびプッシュされないようにしました (タグは引き続き作成およびプッシュされます)。
  • ファイルを PDF に変換CHANGELOG.mdしてチームのメールに送信するスクリプトを作成しました

セマンティック バージョニングはタグを使用して変更されたファイルを判別し、バージョンを上げる方法を決定するため、これはうまく機能します。したがって、レポ内のバージョンは一定のまま1.0.0ですが、セマンティック バージョニングは十分にスマートで、最新のタグからではなく最新のタグからバージョンをインクリメントします。package.json

残念ながら、これはまだタグを使用して変更されたファイルを特定するLernaには当てはまりませんが、内部のバージョンからバンプしますpackage.json。つまり、新しいバージョンで更新されたものをプッシュしないことによりpackage.json、Lernaは常に、、1.0.0または1.0.11.1.02.0.0

だから私はLernaに困惑しています。

質問

この問題を回避するには、CI/CD をどのように設定すればよいですか? 私のレポの構造が一般的であることは知っています.Lernaとセマンティックバージョニングの無数のユーザーにもかかわらず、この問題に対処している人は誰もいません.

考えられる解決策

devこの質問を書いているときに、バージョンをバンプしてからデプロイするだけでよいのではないかstageと思いましたmaster。これは を防ぎstage、master先をdev行くことはありません。これは正しい方法でしょうか?

4

1 に答える 1

1

リポジトリでパッケージのバージョン情報を維持しても、スケーリングされません。それでも、そこにあるすべてのツールは、それを機能させようとし続けています. それを言う以外に、私は（まだ）代替手段として提供するものは何もありません。リリース データは、ソース リポジトリに保存する以外の方法で管理する必要があります。ここで実際に話しているのは、非同期プロセス、dev、build、および release です。これらのシステムの分散型の性質は、リポジトリをファイル共有として扱うことができず、それらが適切にスケーリングされることを期待できないことを意味します.

このトピックに関する私の他の暴言を参照してください。私はまだこれについて良い記事を書く時間がありませんでした. Git タグは、開発者が戻って修正ブランチを作成するための適切な git ハッシュを見つけるための便利なマイルストーン マーカーであることを付け加えておきます。コミット メッセージは変更ログ用であり、どのビルドからどのバージョンをリリースするかを決定するための入力の 1 つにすぎません。

マルチ開発、マルチブランチ、分散環境で作業している開発者は、将来のランダムな時点で適用する適切なセマンティック バージョンを予測することはできません。少なくとも、すべての開発、ブランチ、およびビルド/リリース環境を完全に独裁的に制御する必要があります。それでも、彼らはそれを機能させるのに苦労するでしょう。現在のツールが暗示しているのはその制御ですが、実際には、決してスケーリングしません。

パッケージ フィード サービスには、リリース履歴のすべてまたは十分な部分が含まれている可能性が高いと考えてください。フィード サービスが 1 つしかない限り、それを使用して次のリリースのバージョン フロアを決定できます。セマンティック コミットを処理し、プロセスが対象とするタグ (毎日、ベータ、RC、なしなど) に一致する最新バージョンを検索し、次の適切なバージョンを計算し、ソース コードの適切なバージョン フィールドを更新してから、ビルドしてテストします。フィード サービスで非表示または削除されたバージョンをクエリに含めることができない場合は、独自のデータベースを使用する必要があります。変更されたファイルをチェックインしないでください。これらのフィールドはレポでゼロにする必要があり、ローカル開発ビルドを 0.0.-dev またはそれらの線に沿ったものとして効果的にマークする必要があります。

プレリリース バージョンの自動発行は問題ありませんが、リリース バージョンのループには人間が必要です。上記のすべての手順が成功した場合は、ビルドに成功した git ハッシュにタグを適用します。

私の夢の CI/CD システムは、テスト ビルドと単体テストの実行を通じてリリース ブランチへのすべてのコミットを実行し、既存のテスト ケースが変更されたかどうかを検出し (重大な変更を自動検出します!)、意図的な変更の兆候がないかコミット メッセージを分析します。そのすべての情報をオンデマンドでリリース ビルド システムに提示します。私のリリース ビルド システムは -alpha.build.### を生成し、それに対してすべての受け入れテストを実行します。

既知の破損がなく、意図したターゲットがプレリリースである場合、バージョン情報を含むファイルを更新し、自動公開の前に 1 つの最終スモーク テストでインクリメンタル ビルドを実行します。ここには、いくつかの灰色の領域があります。一部のプレリリース ターゲットには、人間の介入なしに破損を含めるべきではありません。そのため、特定のレベルのドッグフーダーや、社内の長時間実行テスト インフラストラクチャを対象としたビットなど、破損の自動公開を許可しないプレリリース ターゲットの特別なセットを用意します。

タグなしのリリース ターゲットである場合は、テストの最終段階で使用するためにすべてをビルドしてパッケージ化することをお勧めします。これは、自動化がパッケージのポリシーへの準拠を検証し、正しく解凍できることを確認し、公開前にエリアの所有者、部門/部門長などからのサインオフを収集する場所です。ライブ システムをターゲットにしている場合は、ランダム化されたテスト展開が含まれる場合があります。

そして、上記のすべては、実際には過度に単純化された説明です. 生産者と消費者の現実世界のニーズにはあまりにも多くのばらつきがあるため、明確にする以上のことを詳しく説明しています。

ツールとコントロールに戻ります。DevOps の世界には、主なポイントはツールを中心に標準化することだと言う人がたくさんいます。この xkcd コミックを思い出します。

于 2021-04-01T19:55:20.597 に答える