2

スクラム環境で作業するデリバリー チームとともに、コア システムのゼロからの書き直しを提供しています。チームの規模が大きいため、コードを日常的に統合することを目的とした 2 つのスクラム チームに分割しました。テスト チームがシステム テスト環境に (通常は毎日) デプロイするたびに、データベースを破棄し、すべての参照データを再入力します。これは、テストのベースラインを確保するためです。

このアプローチの問題点は、テスト チームの 1 つが修正の展開を待っていて、もう 1 つのチームがテストの実行中にいる間に、ベロシティに大きな影響を与えることです。これを解決するために、次のことを提案しました。

  • 別のテスト環境の作成 (非常に費用がかかります) に加えて、チーム内の 1 人のテスターがまだ修正を展開できないため、遅延が発生します。
  • コードのみの展開のオプション (データベースの破棄を回避)。

私たちは、チームがクロスファンクショナルであることを奨励し、テスターが展開を妨げているテスターを支援することを奨励していますが、これは常に実用的ではありません. また、タスクは約 1 ～ 2 日間の作業になることを目指しているため、アイテムの期間を簡単に分類することはできません。

他の人が彼らの環境で採用したアプローチは何ですか?

4

1 に答える 1

2

分解して最初からやり直すのではなく、構造の変更（テーブルの追加、列の名前変更など）とデータの移行の両方を行う「デルタスクリプト」として各変更を定式化することにより、データベースを「進化」させるアプローチを検討してください。

私はこのアプローチを数回使用しましたが、それが定着したとき、それは大成功でした-チームと各開発者の両方が大幅に速く動くことを可能にしました。

興味があれば、私の取り組みの1つを説明するブログ投稿があります：http：//dearjunior.blogspot.se/2008/05/version-of-data-in-database.html

詳細を知りたい場合は、 「データベースのリファクタリング」をお勧めします

私たちが最も遠くに到達したチームは、すべてを管理するためにトラック一杯のbashスクリプトを開発しました。ただし、最近では、いくつかの優れたフレームワークもあります。私たちは実際に私たち自身が開発したものと非常によく似たdbmaintainを使い始めました。

このアプローチを徹底的にお勧めします。

[更新]ソフトウェアエンジニアリングラジオがほんの数か月前にこのトピックに関するポッドキャストエピソードを実行したことに出くわしました。

于 2012-09-06T21:10:03.090 に答える