マネージャーは、開発と本番環境の組み合わせを望んでいます
私は、より大きな組織をサポートする小さなプログラミングチームで働いています。今年のマネージャーは、Oracle Apexテクノロジーを使用して会社のデータの大部分を処理することを決定しました。
Apexサーバーが1つしかない場合を除いて、これで問題ありません。私たちの上司は、すべてがその1つのインスタンスで発生することを決定しました。私たちのチームはアプリを開発していますが、私たちのマネージャーはそれらをデモし、内部クライアントはそれらを使用しています。これは明らかな理由ですでに問題を引き起こしています！
Apexへの投資が大きくなり、アプリがより複雑になり、ユーザー数が増えるにつれて、これが悪化することだけが予想されます。ベストプラクティスは、開発、テスト、本番環境を別々にすることだと聞きましたが、なぜこれが当てはまるのですか？
質問：なぜ開発、テスト、本番環境を分離する必要があるのですか？
開発、テスト、本番の環境を分離する必要があるのはなぜですか？
いくつかの活動が同時に進行しています：
- 開発-開発者がコードをコミットしたり、間違いを犯したり、実験したりする...
- テスト-テストが手動または自動で実行され、複雑さのために多くのリソースを消費する可能性があります。
- 生産-顧客やビジネスに価値を生み出す場所
これらすべてを同じ環境で実行しますか？新しいテストでサーバーがハードドライブの交換に追い込まれ、プロセッサのすべてのコアを消費しているため、ビジネスを停止させたいですか？開発者がスケーリング実験から複雑なフォーク爆弾を作成したため、テストを停止して停止しますか？テストでの開発者の絡みとダクトテープのために機能したと思われるコードを本番環境で実行しますか？機密性の高い本番データを扱う開発者を望んでいますか（これはすべてのビジネスで問題ではないことはわかっていますが、多くのビジネスで問題となっています）。
これらの問題の発生を防ぐものは何ですか？
別々の環境。
それであなたは何が必要ですか？
別の環境が必要です。
正式に言うと
次の理由により、個別の環境が必要です。
- ビジネスおよびソフトウェア開発をブロックするリスクを減らすため。
- 開発者のアドホックなリギングが原因でテストに合格したコードを本番環境に配置するリスクを減らすため。
- 本番データが悪用されるリスク（組織がID番号や財務情報や健康情報などの機密データを扱う場合に非常に重要）、またはテストデータが混在したり破壊されたりするリスクを減らすため。
コンテキストに応じて、新しいテクノロジープラットフォーム
多分これはまだ本番稼働ではないかもしれませんが（比較的新しいプラットフォームであるため）、ビジネスがそれに依存し始めたときに個別の環境が得られ、リスクを予測するか、ハードに学ぶことでそれを実現するのに十分賢明です仕方。
ベストプラクティスは、開発、テスト、本番環境を別々にすることだと聞きましたが、なぜこれが当てはまるのですか？
最近はそれほど明確ではありません。
多くの場所では手動テストを行わないため、テストデータ自体はありません。さらに多くの場所でそのような規模があり、コストのために本番環境を再現できません。また、特にマイクロサービスの爆発的な成長に伴い、QA環境でのテストにより、本番環境で発生するバグを正確に再現できるように、急速に変化する環境の同期を維持することが困難になっています。
なぜ開発、テスト、本番環境を分離する必要があるのですか？
- テストデータをユーザーに見せるのは非常に悪いことです。
- 開発者/テスターがあなたの製品データを見ることは非常に悪いでしょう。
- 開発者が物事をひどく壊さないように信頼できず、その状況を迅速に修正できない場合。
- コードのプロモーションが迅速かつ簡単になるように自動化されたCIを導入している場合。
基本的に、環境を持つことのコストがnot環境を持つコストよりも低い場合。
主な（そして最も明白な）理由は、テストデータと実稼働データを混在させたくないということです。これは、システムのユーザーと開発者の両方にとって、非常にすぐに混乱する可能性があります。品質保証と単体テストを管理している場合（これを行う必要があります）、それらが完全に分離された環境にあることを確認する必要があります。開発環境またはQAで何かが爆発した場合、本番に悪影響を及ぼし、ライブユーザーとその重要なデータに悪影響を及ぼします。あなたは絶対にこれが生産に影響を与えたくない！
これは、バージョン管理などの日常業務で使用する必要がある通常のサービスにまで及びます。制御しているコードがライブ環境にある場合、バージョン管理を適切に利用できない可能性があります。ユーザーは狂っています-元に戻すまたはロールバックする必要がある場合はどうなりますか？ 15のコミットを大幅に犯した場合はどうでしょうか。分岐をどのように処理しますか？
少なくとも、環境をいくつかの仮想インスタンスに分離する必要がありますが、実際には、発言したとおりに実行し、環境ごとに完全に別個のインスタンスを作成する必要があります。理想的には、開発、QA、ステージング、プロダクションです。
これらすべては、最終的には、アプリケーション（およびユーザーに対する評判）だけでなく、チームの効率にも多大な損害をもたらします。
使用できるOracleインスタンスが1つだけであっても、「開発、テスト、本番環境を分離しない」という意味ではありません。
コメントに書き込んだ
現在、プロジェクトごとに異なるスキーマを使用しています
わかりましたので、開発専用のプロジェクトとテスト専用のプロジェクトを用意することで、異なるスキーマを使用して、環境をある程度分離できます。インスタンス分離が計画されていないときに私が知っている唯一の賢明なアプローチだからです。あなたのマネージャーが気が狂って、開発データ、テストデータ、顧客データをすべて1つのスキーマに任意の方法で混在させることを望んでいるとは思えません。彼はおそらく、2つ目のサーバーを購入したり、2つ目のインスタンスのライセンスにお金を投資したりしないことで、お金を節約したいと考えているでしょう。
したがって、必要なreal質問は次のとおりです。
開発、テスト、本番環境を分離するために異なるインスタンスやサーバーを使用する必要がありますか、それともスキーマの分離で十分ですか？
そのため、ここでの他の回答のように、答えが明確ではありません。スキーマが異なればアクセス権も異なるため、少なくとも1つのOracleインスタンス内である程度の分離を実現できます。ただし、開発者はおそらく「自分の」スキーマ内の管理者権限を必要とするため、1つのインスタンスを使用するだけでは、本番データにアクセスできないようにすることは困難です。
さらに、1つのインスタンス/ 1つのサーバーは、開発、テスト、本番の間の共有リソースを意味します-共有ユーザー/スキーマ管理、共有ディスクスペース、共有CPU、共有ネットワーク帯域幅。これを "漏洩の抽象化の法則" と組み合わせると、1つのインスタンスだけを使用すると、開発環境、テスト環境、本番環境の間で望ましくない副作用が発生するリスクがあることが明らかになります。
最後に、自分で決める必要があります。アプローチの欠点を効果的に処理できますか？アプリケーションはリソースを大量に消費せず、本番データは「秘密」ではないので、「3つのインスタンス/ 3つのサーバー」から取得するレベルよりも開発、テスト、本番間の分離のレベルを下げることは許容されますかアプローチ？その方法で効果的に作業できない場合、または顧客を失い始める方法で生産を妨害する高いリスクがない場合、マネージャーに少なくとも2台目のサーバーを購入するよう説得するために必要なすべての議論があります。
複数の環境タイプが必要であり、各環境に複数のサーバーが必要な場合もあります。
開発者は開発中のコードを更新できます。コードも機能しない可能性があります-おそらくアプリケーションも起動しません。
独自の環境で最新の安定したビルドをテストしているQAには影響しません。
開発とQAの両方で環境が更新されているため、本番環境は6か月前からビルドされた最新のリリースであり、他の環境の変更による影響は受けません。
さまざまな環境で展開されるこれらの変更は、コードまたはデータである可能性があります。おそらく、QAは本番環境でいくつかの不良データを修正するように設計されたデータベーススクリプトをテストする必要があります。スクリプトが問題を悪化させているのかもしれません-データベースのバックアップを復元して、再試行してください。それが本番環境で発生した場合、非常に深刻な財政上の問題が発生する可能性があります。
複数のリリースがある場合はどうなりますか？バージョン2.0を開発している可能性がありますが、1.0メンテナンスブランチにはバグ修正リリースが必要です。重大なバグが発見され、昨日修正する必要がある場合に、いずれかのブランチを常に開発およびテストできるようにするには、複数の開発環境とQA環境が必要です。
notに個別の環境があることによって引き起こされる問題にすでに気づいています。そこには、別々の環境の根本的な理由があります。単一の環境で開発、テスト、本番運用を行うときに必然的に発生する競合によって引き起こされる問題を排除するためです。同じ理由が、開発者に個別のサンドボックスを提供する場合にも当てはまります。これにより、1人の開発者のミスや、互換性のない変更でも、開発チーム全体が機能しなくなるのを防ぎます。
これは、単一の環境から離れて変化するために管理に対して行うことができる最良の議論でもあります。単一の環境がすでに引き起こしている問題を指摘し、傾向線を示し、物事が続くので物事が続く場合は遅かれ早かれそれを主張します。個別の環境に合わせて再構成するよりも、クリーンアップにかかるコスト（直接的な努力と、サービスを提供するという会社の能力に対する顧客の信頼の喪失の両方）にかかるコストがはるかに高くなります。