0

製品は、リリースではなく機能として開発および提供されます。つまり、機能が完了すると、ステージングにプッシュされてから本番環境にプッシュされます。開発中の複数の機能があり、配信タイムラインが重複している可能性があります。そのため、いつでも開発データベースとソース管理には開発中の複数の機能があります。機能が完成したら、機能固有のコードとデータベースの変更のみをステージングにプッシュしたいと考えています。このプロセスは、次の理由により、エラーが発生しやすく、時間がかかることがわかっています。

  • 特定の機能の DB エンティティは独立していませんが、依存しており、他の機能と絡み合っています。そのため、機能に固有のエンティティを分離するのは時間がかかり、達成が困難な場合もあります。それを行うより良い方法はありますか？
  • サーバー側のコードでは、同様に機能固有のコードを分離することは、データベースと同じくらい面倒です。DB の上にレイヤー化された .NET Entity Framework と、事前に生成されたビューなどの他のパフォーマンスの最適化を使用して、機能ベースの開発をデプロイするより良い方法はありますか?

開発環境は、SQL Server 2008、.NET、ソース管理用の SVN を備えた Entity Framework で構成されています。

ここでの機能という用語は、FDD アジャイル モデルとは関係ありません。

似たような経験をした人はいますか？

どうもありがとう！

4

1 に答える 1

1

私は、あなたが今説明したものと非常によく似たプロジェクトを管理しています。

できるだけ早く SVN と CruiseControl.NET のセットアップを入手してください。それは人生/時間の味です

現在、チームは SVN のブランチで作業しており、トランクにマージしてから、本番の準備ができたらタグを付けています。

データベースをバージョン管理下に置き、バージョン番号をタグ (リリース) に関連付けます

DB のバージョン管理に役立ついくつかのテーブル/制約/トリガーを作成することを提案するこの素晴らしい記事に基づいて、独自の DB バージョン管理方法を導き出しました。

データベースのバージョン管理は最も難しい部分です。DB を変更するための厳密なルーチンを開発する前は、すべてが悪夢でした

明らかに、完全な詳細を説明するのに十分なスペースはありませんが、コードの管理/マージに丸一日を費やすことから、安心してプロジェクトに貢献する時間を確保するために自動ビルドをチェックインするようになりました.

于 2010-02-18T04:41:59.757 に答える