我慢してください....
(編集...)
╔════════════╦═══════════════════╦══════╗
║ repo name ║ role ║ user ║
╠════════════╬═══════════════════╬══════╣
║ RepoMain ║ production ║ Mr.A ║
║ RepoTest ║ test server ║ QA ║
║ RepoB_vm ║ Mr.B's vm ║ Mr.B ║
║ RepoB_home ║ Mr.B's final repo ║ Mr.B ║
║ RepoC_vm ║ Mr.C's vm ║ Mr.C ║
║ RepoC_home ║ Mr.C's final repo ║ Mr.C ║
╚════════════╩═══════════════════╩══════╝
A 氏は他の人と共同作業をしているので、自分のリポジトリを持っていると想像できます (同じプロジェクト)。
私がまだ終わっていないと思うホットな初心者の質問がいくつかあります。
独自の VM (仮想マシン) で動作する基本的なワークフロー
変更をコミットします --> テスト サーバーから Repo_vm にプルします --> vm でテストを実行します --> 成功したら、QA に Repo_home からプルするよう依頼します
これは可能な限り最良のワークフローですか? 私は常にマージの問題を恐れています(新しい変更が失われることもあります..私はそのひどい経験をしました)。実稼働 <--- テストサーバーは一方向なので、大したことはないと思います。それは安全なマージのように聞こえます。
しかし、複数の開発者が同じテスト サーバー リポジトリを使用している場合、これを行うと、Michael Myers に追跡されることになります。
上記のワークフローをより明示的に拡張するには...
- vm で変更をコミットする
- テストサーバーからプル
- VM でテストを実行する
- すべてパスしたら、ホーム リポジトリを更新します
- QA に repo_home からプルするよう依頼する
プルリクエストを念頭に置いて、これはより良いワークフローですか?
- 自分の VM で変更をコミットする
- 最新のアルファ版のテスト サーバーから変更をプルする
- テストをローカルで実行する
- すべてがうまくいけば、自分のアカウントでホームリポジトリにプッシュします
- プルリクエストを送信する
- キューの先頭にいる場合は、テスト サーバー (サンドボックス環境) でクローン バージョンを作成してから、マージを行います (テスト サーバーには、ホーム リポジトリでコミットされた最後のアルファ バージョンとは異なる最新バージョンがある可能性があります)。
- テストに合格したら、マージされたサンドボックス リポジトリから取得するように QA に指示します。
- テストを実行する
- scheulde で本番環境にプッシュ
Q2: QA に限られた時間を与えるとはどういう意味ですか?
Q3: 開発者はどのくらいの頻度でテスト サーバー (最新の安定したアルファ版を含む) からプルする必要がありますか?
ありがとう。