アジャイル開発のベストプラクティス
1. 全体の流れ
- 1. 需要計画: アウトプット -> ユーザーストーリー
- 2.スプリント計画会議: 出力 -> スプリントバックログ (タスクリスト)
- 3. デマンド確認：出力→PRD
- 4.毎日のスクラムミーティング: 毎回のスタンドアップミーティング
- 5.コーディング: 出力 -> コード
- 6.テスト: 出力 -> テストレポート
- 7.スプリントレビューミーティング: 出力 -> ミーティング議事録
- 8. 会議のレビュー: 出力 -> 会議議事録
2. バージョン管理
Gitflow を全体として採用し、実際の状況と組み合わせると、全体的なプロセスは図のようになります。
- 1. prod から dev ブランチを切り出します。
- 2. dev ブランチから feature ブランチを切り出す
- 3. feature ブランチの新しい機能が開発された後、コードを dev ブランチに送信します。
- 4. すべてが正しいことを確認した後、研究開発の学生は、dev ブランチを test ブランチにマージするためのマージ リクエストを送信します。
- 5. テストのクラスメートはマージに同意します。コードがマージされると、自動ビルドがトリガーされ、イメージが自己構築されたイメージ ウェアハウスにプッシュされ、自動的にデプロイされます。
- 6. テスト環境が正しいことが確認された後、テスト生はテスト ブランチをプレ環境にマージするためのマージ リクエストを送信します。コードがマージされた後、自動ビルドがトリガーされ、イメージがセルフビルドにプッシュされます。ミラーウェアハウスに保存され、自動的にデプロイされます。
- 7.本番環境の操作は上記のステップ 6 と同じです。
2.1 コミット要件
コミット メッセージでは、このコード変更に何が関係するかを明確に説明する必要があります。これは、テストを行う学生にとっては、漏れを避けるためにこの変更に回帰テストが必要かどうかを知るのに役立ちます。研究開発の学生にとっては、後から問題が発生したときに、どのコミットに問題があるのかを簡単に特定できます。
アジャイル開発では、小さな機能が完了するたびに、変更を頻繁に送信することをお勧めします。一般に、コミット メッセージは次の形式を指します。
- feat：新機能、新機能（フィーチャー）、要件番号を持ってくる
- fix: バグを修正します。バグ番号がある場合は、バグ番号をご持参ください。
- ドキュメント: ドキュメント
- style: コード形式の変更 (比較的小さなコード変更ですが、機能は変わりません)
- テスト: テスト ケースを変更するか、テスト コードを追加します。
- リファクタリング: コードの再構築、内部処理ロジック/アルゴリズム ロジックの大幅な変更 (つまり、バグを修正するための新しい機能やコード変更ではありません)
- chore: ビルド プロセスや補助ツール (ビルド プロセス、依存関係管理など) への変更 (これは、未決定のサブミットに推奨されます)
2.2 タグの要件
バージョンが正式にリリースされるたびに、タグを付ける必要があります。タグは通常vX.YZの形式で、X はメイン バージョン番号、Y はマイナー バージョン、Z はメンテナンス バージョン番号です。具体的な意味は以下の通りです
- X = メジャー バージョン番号 (メジャー アップグレード、異なるメジャー バージョンのライブラリには互換性がありません)
- Y = マイナー バージョン番号 (増分アップグレード。いくつかの新しいインターフェイスを追加しますが、元のインターフェイスは保持します。上位バージョンのライブラリは、下位バージョンのライブラリと下位互換性があります)
- Z = メンテナンス バージョン番号 (バグ修正のみ) (エラーの修正、パフォーマンスの向上など。新しいインターフェイスの追加やインターフェイスの変更はありません。メジャー バージョンとマイナー バージョンが同じであるという前提の下、メンテナンス バージョンが異なります)完全に互換性があります)
2.3バージョンアップデートログ
バージョンにタグを付ける前に、このバージョン更新の内容を Readme に記述する必要があります。
2.4 SQLの更新とメンテナンス
データベースのテーブル構造を変更する変更の場合は、sql/update/にテーブル構造を更新する文を追加する必要がありますが、運用保守学生がバージョンリリースを行う場合は、まずupdate文を実行してから実行する必要があります。サーバ。同時に、sql/all.sql ファイルでは、テーブル構造データの全量を維持する必要があります。