データアクセスレイヤーのボーガーティング

状況：dbaは、DALコード全体をTFSでチェックアウトしたままにするオフサイトの請負業者です。フロントエンドの開発者として、列を追加したり、プロシージャなどを調整したりできます。この男がメールに応答して作業を行うのを待つ必要はありません。

質問：データの整合性とチーム間の平和への愛と幸福を維持しながら、より迅速で機敏な開発を可能にする推奨ソリューション/プロセスは何でしょうか？

マーティン・ファウラーとプラモド・サダレージは、この問題について優れた記事を書いています。

すべての開発者は、変更を加えることができる独自のデータベースを持っています。その後、これらの変更は（チェンジセットとして）マスターデータベースに実装するDBAに伝えられるため、プロセスに関与しているため、おそらくデータベースの構造とニーズについて最もよく知っています。これは、プロセスに関与するすべての人にとって満足のいくものであり、非常に機敏なため、これが最良のアプローチだと思います。

同様の方法でDALを変更できます。変更を加え、完了したと思われるときにDBAに変更セットを提供するだけで、DBAはそれを確認してマスターにマージできます。

Wellll、私がDBAのことをしているとき、私はすべてをロックして、いまいましいダーティプログラマーがその目的を達成できないようにすることが知られています。誰もがそれをよりよくする方法を知っていると思っており、彼らは物事を「微調整」して自分のために簡単にし、それは不道徳な混乱を引き起こします。

他の選択肢は、それを大きく開いてプログラマーにしばらくの間近づかせ、次にジャンプして、物事が終わりに近づき始めるときに順序を課すことです...これは確かにより「機敏」ですが、何を切り取ったり変更したりする必要があるかによる実際の悪夢... DBAはプロジェクト全体をよく理解していることが多く、無害に見える変更によって問題が発生する場合があります。

彼が唯一の門番になる場合、彼は固定された仕様を持っているか、残りの開発者に自分のビジョンを「売り込む」ことができる必要があります。

他の問題に取って代わる大きな問題があります：

1. 請負業者が常にコードをチェックアウトしているのはなぜですか？

なぜ彼はこれを許されているのですか？積極的に編集を行わない限り、ファイルをチェックアウトしてはいけません。チェックアウトに関するチームポリシーが必要です。

請負業者は（気に入ったかどうかにかかわらず）チームの一員として働き、場合によってはチームの他のメンバーが変更を加える必要があります。これはコミュニケーションの問題です。残念ながら、この通信の問題を自動的に修正する方法はありません。

水平のレイヤーの代わりに、私はサイロのレイヤー全体で作業することを好みます。

そうすれば、この方法で1人/チームがブロックすることはできません。

また、開発者はマルチスキルであり、機能をより簡単に移動できることも意味します。

もちろん、さらに専門的な作業が必要になる可能性のあるセクション（UI設計、DB設計）もありますが、アイデアは理解できます。

単純です。まだの場合は、3つの環境が必要です。

• 開発環境
• QA環境
• 本番環境

開発環境は開発者が管理する必要があります。

RC環境を追加することもできます。

もう1つの答えは、複数の環境が不可能な場合は、モックされたリポジトリに対して開発することです...この方法でモデルを構築し、モデルをDBに一致させるのは請負業者の責任です。ある意味では、開発者がデータベースについて心配する必要がなくなるため、これはより良い方法です。

あなたの問題は私には人力の一つであるように見えます。データベースのすべての潜在的な変更がデータベースの専門家によって承認されることは適切であり、必要です。現在の担当者がタイムリーに仕事についていけない場合は、さらにデータベースの専門家が必要です。

これは技術的な問題と同様に管理上の問題です。

DBAが（オンサイトかオフか、請負業者か従業員かに関係なく）開発者がデータベースの変更を行わないようにする理由は確かにあります。

ただし、定義した主な問題は可用性の1つです。あなたのマネージャーは、この人を待つのに時間/お金が浪費されていることを知っていますか？そうでない場合は、誰もがどのように座っているかを示すことができます。