本番データに対して開発するのは悪いことですか？

生産データに対して開発することは悪い習慣であり、現在Dev> Stage> Productionモデルに移行している最中であるといつも聞いていました。これは、主に最小限のスキルを持つ新入社員がいて、彼がいないからです。まだ生産データを直接操作します。

しかし、長い間頭痛を最小限に抑えながら、本番データを直接操作してきました。ただし、スペリングの問題、不適切なaltテキスト、間違った場所を指すリンクなど、多少のエラーが発生する可能性があります。これは、ライブデータでの作業が原因ではなく、私の側でのピアレビューの不足が原因のようです。

では、なぜライブサイトでの開発がこのように悪い習慣なのか

開発中に、既存のデータベーステーブルを含む、INSERTまたはUPDATE既存のデータベーステーブルでSQLコマンドを実行している場合、それらのデータベーステーブルがミッションクリティカルであるという程度のリスクが発生しています。

一部の場所では、一定の間隔で（たとえば、週に1回または開発者の要求で）本番データを開発データベースに同期して、新しいデータを開発できるようにします。

しかし、たとえば、データのビューを開発しているだけの場合など、運用データが実行中のリスクにさらされていない場合、通常、それは大した問題ではありません。テーブルスキャンを実行するレポートを実行している場合、テーブルをロックする可能性があり、既存のユーザーが影響を受けます。

このような場合は、データベース管理者に委ねます。「公式」のDBAがいない場合は、注意が必要です。私自身でも、開発データベースを作成するのは簡単です。チームにとってそれは非常に重要です。失敗した場合、1つのデータベースのみを使用することにしつこい場合は、開発データベーステーブルにプレフィックスを付けてDEV_、少し気分を良くすることができます。はい、それはいくつかのコード変更を必要としますが、開発では開発中にいくつかの変数を追加する$debug = trueなど、通常は努力する価値があります。

これに取り組む多くの方法。それはあなたの状況に非常に依存しています。

本番サーバー上の本番データに対して開発する必要はありません。いくつかの大きな理由があります。

1. 開発は生産ボックスを遅くし、脆弱性を生み出します。コンピュータのロックを解除したまま離れると、どうなりますか？
2. 間違えた場合、サイトにアクセスした人はそれを見ることができます。
3. データベースのトランザクション内で何らかの種類のデータ更新を行い、それをすぐにコミットしない場合、またはトランザクションが完了するまでに時間がかかる場合、関係するすべてのテーブルにロックがかかり、タイムアウトが発生する可能性があります。
4. 一部のデータベースシステム、特にSQL Serverは、SELECTステートメントだけでテーブルロックを行うことがあります。つまり、意図せずにサイトのタイムアウトやエラーページを表示する可能性があります。

できれば、ライブボックスでの開発作業は決してしません。あなたの最善の策は、データベースとページのバックアップを作成し、コピーを操作して、更新をプッシュすることです。MsftのSyncToyは、私を支援してくれたツールの1つです。

まあ、あなたは本当にそれをデータに台無しにすることができます。where句を省略することを想像してみてください。1時間ごとのバックアップがある場合でも、修正するのは面倒です。

シートベルトなしで運転しない場合は、本番データで開発しないでください。ただ安全上の問題です。

本番データを利用できる場合は、それらをテストに使用するのが妥当ですが、そのデータのコピーを含む別のテストデータベースを使用してください。そうでない場合、いくつかの「blabla」テストレコードでは多くのことが機能しますが、実際のシナリオでは機能しません。

また、ライブプロダクションデータで開発する場合は、マーフィーの法則「失敗する可能性のあるものはすべて失敗する」を覚えておいてください。