創造を続け、成長を加速させましょう！「ナゲッツデイリーニュープラン・6月アップデートチャレンジ」に参加して2日目です。クリックしてイベントの詳細を表示
現在、ほとんどの企業がgitを使用してコードを管理しています。今日は、当社のバックエンドコードのgit管理プロセスを共有します。
ブランチの説明
| 支店名 | 対応する環境 |
|---|---|
| 発展させる | 研究開発サーバー |
| テスト | テストサーバー |
| 主人 | 本番サーバー |
| 特徴 | ローカルサーバー |
| masterBugFix | ローカルサーバー |
| testBugFix | ローカルサーバー |
通常バージョンの反復プロセス
- 開発段階
- 最初に最新の開発ブランチのコードをプルします。
- 以前のバージョンのdevelopのコードがテストブランチにマージされていることを確認してください。
- 開発ブランチに基づいて、独自の機能開発ブランチを作成します。
- 機能ブランチの命名方法：機能/人名/機能名/バージョン番号。
- テストフェーズ
- 関数の開発が完了したら、最初に開発ブランチをリベースしてから、関数ブランチのコードを開発ブランチにマージできます。
- R＆Dサーバーでのセルフテストに合格した後、開発ブランチコードをテストブランチにマージできます。次に、コードテストを行います。
3.バグ修正フェーズのテスト
- 最初に最新のテストブランチコードをプルします。
- テストブランチに基づいてテストバグ修正ブランチtestBugFixを作成し、バグ修正が完了した後にコードをマージします。testBugfix->test->develop。
4.バージョンオンラインステージ
- テストに合格すると、テストブランチのコードがマスターブランチにマージされ、タグにマークが付けられます。その後、オンラインに接続できます。
公式サーバーのバグ修正プロセス
- 最初に最新のマスターブランチコードをプルします。
- マスターブランチに基づいて、公式のサービスバグ修正ブランチmasterBugFixを作成します。
- 公式サーバーのバグ修正が完了した後、コードはマスターブランチにマージされ、マスターブランチコードがテストのためにテストサーバーにアップロードされます。テストが失敗した場合は、テストに合格するまでmasterBugFixブランチのコードを変更し続けます。
- バグ修正が完了した後、コードがマージされ、マスター->テスト->開発されます。
以上が紹介したいプロセスですが、実はそのプロセスはどうあるべきかを定めたものではなく、自社の開発プロセスに合わせて策定する必要があります。紹介したプロセスは、ご利用に適さない場合があります。私のこのプロセスには実際に問題があります。公式サーバーのバグ修正プロセスでは、バグが修正されてテストされた後、コードがカバーされているため、テストサーバーでテストされている作業を停止することしかできません。公式サーバーを待つ必要があります。バグが修正されたら、テストサーバーのコードをテストブランチのコードに復元して、テスト作業を続行できます。したがって、完璧なプロセスはありません。あなたにとってうまくいくものは良いことです。欠陥があるので、これらの欠陥が私たちに不必要なトラブルを引き起こさないようにいくつかの仕様を使用してください。したがって、プロセスを制約するための対応する仕様が必要であり、これは良いプロセスです。
見てくれてありがとう！
よろしくお願いいたします。街灯！