私は大規模な組織をサポートする小さなプログラミングチームで働いています。今年、マネージャーは、Oracle Apexテクノロジーを使用して会社データの大部分を処理することを決定しました。

Apexサーバーが1つしかないことを除いて、これは問題ありません。マネージャーは、すべてがその1つのインスタンスで発生することを決定しました。私たちのチームはアプリを開発していますが、マネージャーはそれらをデモし、社内のクライアントはそれらを使用します。

Apexへの投資が増え、アプリがより複雑になり、ユーザーの数が増えるにつれて、これが悪化すると予想されます。ベストプラクティスは、開発環境、テスト環境、および運用環境を別々にすることだと聞きましたが、なぜそうなのですか？

質問：開発環境、テスト環境、および運用環境を個別に用意する必要があるのはなぜですか？

開発環境、テスト環境、および運用環境を個別に用意する必要があるのはなぜですか？

複数のアクティビティが同時に進行しています。

• 開発-開発者がコードをコミット、ミス、実験などを行う場所
• テスト-手動または自動でテストを実行し、複雑さのために多くのリソースを消費する可能性があります。
• 生産-顧客やビジネスに価値が生まれる場所

これらすべてを同じ環境で発生させたいですか？新しいテストにより、サーバーがハードドライブでスワップされ、プロセッサーのすべてのコアが消費されるため、ビジネスを停止させたいですか？開発者がスケーリング実験から複雑なフォーク爆弾を作成したため、テストを停止させたいですか？テストで開発者の絡みとダクトテープが原因で機能すると思ったコードを本番環境で実行したいですか？開発者は、潜在的に機密性の高い実稼働データを使用して作業しますか？

これらの問題の発生を防ぐものは何ですか？

別々の環境。

それで、あなたは何が必要ですか？

別の環境が必要です。

正式に入れるには

次の理由により、個別の環境が必要です。

• ビジネスおよびソフトウェア開発をブロックするリスクを軽減します。
• 開発者のアドホックリギングのためにテストに合格した本番環境にコードを配置するリスクを軽減します。
• 本番データが誤った手に渡るリスク（組織がID番号や財務情報や健康情報などの機密データを扱う場合に非常に重要）やテストデータと混ざったり破壊されたりするリスクを減らすため。

コンテキストに合わせて、新しいテクノロジープラットフォーム

たぶん、これはまだ本格的な生産ではないかもしれませんが（比較的新しいプラットフォームであるため）、ビジネスがそれに依存し始めて、リスクを予測するか、ハードを学ぶことでそれを実現するのに十分な賢明な環境を手に入れるでしょう方法。

ベストプラクティスは、開発環境、テスト環境、および運用環境を別々にすることだと聞きましたが、なぜそうなのですか？

最近はそれほど明確ではありません。

多くの場所では手動テストを行わないため、テストデータ自体はありません。さらに多くの場所にこのような規模があるため、コストのために運用環境を再現できません。特に、マイクロサービスの爆発的な成長により、QA環境でのテストが実稼働環境で発生するバグを正確に再現できるように、急速に変化する環境を十分に同期させることが困難になります。

開発環境、テスト環境、および運用環境を個別に用意する必要があるのはなぜですか？

• テストデータをユーザーに見せることは非常に悪いことです。
• 開発者/テスターがprodデータを見ると非常に悪いでしょう。
• 開発者がものをひどく壊さないことを信頼できず、その状況をすぐに修正できない場合。
• コードのプロモートが迅速かつ簡単になるように、CIを適切に配置している場合。

基本的に、環境を持つことのコストがコストよりも小さい場合ではない環境を持ちます。

主な（そして最も明白な）理由は、テストデータと実稼働データを混在させたくないことです。これは、システムのユーザーと開発者の両方にとって、非常に迅速に混乱を招く可能性があります。品質保証と単体テスト（実行する必要がある）を管理している場合、それらが完全に分離された環境にあることを確認する必要があります。開発環境またはQAで何かが爆発した場合、本番環境、つまり稼働中のユーザーとその重要なデータに悪影響を及ぼします。これが生産に影響することは絶対に望まないでしょう！

これは、バージョン管理などの日常業務で使用する通常のサービスにまで及びます。制御しているコードがライブ環境にある場合、バージョン管理を適切に利用できない可能性があります！ユーザーは非常識になります。元に戻すまたはロールバックする必要がある場合はどうでしょうか。15回のコミットで深刻なミスを犯した場合はどうなりますか？分岐はどのように処理しますか？

少なくとも、環境を複数の仮想インスタンスに分離する必要がありますが、実際には、あなたが言ったことを正確に実行し、環境ごとに完全に別個のインスタンスを用意する必要があります。理想的には、開発、QA、ステージング、およびプロダクション。

これらはすべて、最終的には、正面向きのアプリケーション（ひいてはユーザーに対する評判）だけでなく、チームの効率にとっても大きな損害となります。

使用可能なOracleインスタンスが1つのみであることは、「開発環境、テスト環境および本番環境を分離しない」ことと同じではありません！

コメントを書きました

現在、プロジェクトごとに異なるスキーマを使用しています

それでは、開発専用のプロジェクトとテスト専用のプロジェクトを用意することで、異なるスキーマを使用して環境をある程度分離することができます。これは、インスタンスの分離が計画されていないときに知っている唯一の賢明なアプローチであるため、すでにこれを行っていると思います。マネージャーが非常に狂って、開発者データ、テストデータ、顧客データをすべて1つのスキーマに任意の方法で混在させてほしいとは考えられません。彼はおそらく、2番目のサーバーを購入したり、2番目のインスタンスのライセンスにお金を投資したりせずに、単にお金を節約したいと考えています。

したがって、尋ねる必要がある本当の質問は次のとおりです。

開発環境、テスト環境、本番環境を分離するために、異なるインスタンスやサーバーを使用する必要がありますか、それともスキーマの分離で十分ですか？

そのため、回答はここの他の回答ほど明確ではありません。異なるスキーマでは異なるアクセス権が許可されるため、少なくとも1つのOracleインスタンス内である程度の分離を得ることができます。ただし、開発者はおそらく「自分の」スキーマ内でいくつかの管理者権限を必要とするため、1つのインスタンスを使用するだけで本番データにアクセスできないようにすることは難しくなります。

さらに、1つのインスタンス/ 1つのサーバーは、開発、テスト、本番間の共有リソース（共有ユーザー/スキーマ管理、共有ディスク容量、共有CPU、共有ネットワーク帯域幅）も意味します。これを「漏れやすい抽象化の法則」と組み合わせると、1つのインスタンスのみを使用すると、dev、test、prod環境間で望ましくない副作用が発生するリスクがあることが明らかになります。

最後に、あなた自身で決定する必要があります。アプローチの欠点を効果的に処理できますか？アプリケーションはそれほどリソース集約的ではなく、実稼働データはそれほど「秘密」ではないため、「3つのインスタンス/ 3つのサーバー」から得られるレベルよりも開発、テスト、および実稼働の分離レベルを低くすることは許容できますアプローチ？効果的にそのように作業できない場合、または顧客を失い始めるように生産を妨げるリスクが高くない場合、マネージャーに少なくとも2台目のサーバーを購入するよう説得するために必要なすべての議論があります。

複数の環境タイプが必要であり、場合によっては各環境に複数のサーバーが必要です。

開発者は開発中のコードを更新できます。コードが機能しない場合があります-アプリケーションが起動しない可能性があります。

自分の環境で最新の安定ビルドをテストしているQAには影響しません。

開発とQAの両方が環境を更新しているため、実稼働は6か月前からの最新リリースビルドであり、他の環境の変更による影響を受けません。

さまざまな環境で展開されるこれらの変更は、コードまたはデータである可能性があります。おそらくQAは、運用中の一部の不良データを修正するために設計されたデータベーススクリプトをテストする必要があります。スクリプトが問題を悪化させている可能性があります-データベースのバックアップを復元して再試行してください。それが本番環境で発生した場合、非常に深刻な経済的問題が発生する可能性があります。

複数のリリースがある場合はどうなりますか？バージョン2.0を開発していても、1.0メンテナンスブランチでバグ修正リリースが必要な場合があります。重大なバグが発見され、昨日修正する必要がある場合に、いずれかのブランチを常に開発およびテストできるようにするには、複数の開発およびQA環境が必要です。

別々の環境がないことが原因で発生する問題に既に気付いています。単一の環境で開発、テスト、および本番運用を行うときに必然的に発生する競合に起因する問題を排除するという、個別の環境の根本的な理由があります。同じ理由が、開発者に個別のサンドボックスを提供する場合にも当てはまり、1人の開発者の間違いや、単に互換性のない変更によって開発チーム全体が不自由になるのを防ぎます。

これは、単一の環境から離れて変化するための管理に対して行うことができる最良の議論でもあります。個別の環境に合わせて物事を再構成するよりも、クリーンアップに多大なコストがかかる（直接的な努力と、お客様の会社のサービス提供に対する顧客の信頼の両方の損失）。

多くの対立する力と力学があります。多くのサーバーを所有するコストと、1台だけを所有するコストがあります。この質問は、単なるデータベース以上のことを伝えると思いますか 私は誤解しているかもしれませんが、それは、有形物対抽象のコストがそこにある体系的な誤解に関連しています

通常、明らかなコストは理解しやすいです。

抽象コストは定量化が難しく、したがって理解が困難です。TechnicalDebt、エラーのコスト、ストレスのコスト、開発者の負担、変更の影響、回帰テスト、ダウンタイムの影響などを説明するのは困難です。

さまざまな環境 環境は通常、データや目的のために分離されています。各環境には異なる機能があります。システムの変化率、すなわち 更新頻度、変更の種類および変更の影響がすべて考慮されます。

さまざまな環境を使用して、変更を簡単にします。

さまざまな環境を使用しているため、変更されていない環境の堅牢性と確実性を提供します。

環境を使用して、変更の影響を検討します。

環境を使用して、変更に伴うコストを削減します。

システムのテストと安定化には多くの費用がかかり ます。安定した環境で行われた投資を確保するために環境を作成します。

チームの規模が小さすぎて、実用的で、コストを削減し、勤勉で実績のあるプロセスパターンを順守できないことはありません。

1つの環境をすべてに使用することは、すべての写真を1つのハードドライブに保存するようなものです。それはできますが、後悔することになります。

堅牢性を確保し、ベストプラクティスに従うためのコストを高く評価していないクライアントや他の人に対処する多くの状況で私がこれまでに経験した証拠を必要とする人もいます。コストが明確に定義されている実際のケースの例をまとめることをお勧めします。