スタンフォード大学では、エンジニアチームが積極的に開発しているOpenEdXコードベースのインスタンスを運用しています。私たちは独自のフォークを以下の場所でメンテナンスしています。 github.com/Stanford-Online/edx-platform 私たちは、edXのメインedx-platformリポジトリ（github.com/edx/edx-プラットフォーム（原文が不明瞭なため、正確な翻訳はできません。）edXのメインリポジトリへのプルリクエスト（PR）を通じてコードをリリースすることを推奨していますが、スタンフォード独自のカスタム機能を定期的に構築しているため、それが不可能な場合もあります。反復作業を通じて、明確に定義されたリリースプロセスを採用し、メインedXリポジトリからのマージと独自のリポジトリの維持の両方のワークフローに対応しています。 マスター ブランチです。多数のユーザーが利用するウェブサイトを運営しているため、リリースの安定性は最優先事項です。そのため、問題のあるコードがリリースに含まれないように細心の注意を払っています。 リリース ブランチであり、リリース プロセスによってそれが容易になります。
私たちは自分自身だけでなく edX にも PR を送信するため、開発環境から edX のリポジトリにアクセスする必要があります。そのため、スタンフォードの開発者のほとんどは、少なくとも 2 つのリモート (場合によっては個人のリモートと同僚のリモートを合わせてそれ以上) を使用して Git 環境を実行しています。 起源、スタンフォードのコードリポジトリ、および アップストリームedXのコードリポジトリである からマスターブランチをチェックアウトし、edXにプルリクエストを送信できます。また、このリポジトリも利用しています。 アップストリーム リリース プロセス中に edX からのコード変更をマージするためのリモート ツールです。
ここで、リリースプロセスを説明する図が必要だと気づきました。私は視覚的に物事を理解するタイプなので、図に表すことで物事を理解します。以下は、開発とリリースのワークフローを説明する図です。
当社の「リリースマスター」システムでは、開発者が交代でリリースを担当するため、この図は特に便利です。この図により、リリースサイクルの一貫性が保たれ、ミスを最小限に抑えることができます。
この図をガイドとして使用したリリース プランは次のとおりです。
1. まず、 rc マスターブランチから分岐し、マージされた開発内容をすべて マスター 前回のリリース以降。
1a. マージしたい場合 アップストリーム リリース に分岐する rc ブランチの場合は、ここでそれを行います。
この時点で、テストできるリリース候補版があり、何も問題がないと確信したら、本番マシンにインストールします。.
2. ブランチをマージします rc ブランチに リリース (これは単純な早送りになるはずです。そうでない場合は、以前のリリースに問題がありました。)
3.今、 リリース ブランチ（およびマージされた アップストリーム コード）を マスター 両方のブランチを相互に同期させるブランチ。
機能ブランチは以下から作成されることに注意してください マスター そして、通常のリリースサイクルに統合されてリリースされます。一方、ホットフィックスは リリース、再び統合された リリースすぐに本番環境にプッシュされ、その後マージされて マスター 同期を維持するためです。また、 リリース 変更と アップストリーム マージは行われない マスター 試験後に安全であると判断されない限り、 マスター バグからも保護します。
以上です。私たちが管理するすべてのフォークされたリポジトリにこのブランチ モデルを使用することで、すべての一貫性と予測可能性が保たれます。
