実際には、開発、テスト、本番環境への展開、本番環境の監視など、対処すべきさまざまな問題がいくつかあります。
通常、データを使用して本番環境から分離された機器で開発を行いたいと考えています。環境は本番環境に似ていますが、テスト ハーネス、デバッガー、ロガー、自動化された単体テストなど、開発を効率的かつ効果的に行うために必要な優れた機能がすべて備わっています。など。ほとんどの場合、本番データは保護する必要があるため、本番データではなく、本番データと同様のデータが必要です。また、独自の製造データを持つ開発により、設計者テストの一部として特定のシナリオのテストが可能になります。
システムのソース コードと機能に変更が加えられたときに、開発者が追加する標準のテスト データ セットを用意することをお勧めします。また、テスト データの追加/変更は、なんらかの考慮が必要な何らかの形式的または準形式的なプロセスを必要とする変更であり、そうしないと混乱してしまいます。エントロピーは、混沌と混乱に向かう傾向のある物理システムと同様に、ソフトウェア システムにも当てはまります。
テスト環境は、開発環境から分離し、本番環境にできるだけ近づける必要があります。おそらく、2 つのバージョンのテスト環境が必要です。1 つは追加のデータ キャプチャ機能をテストするためのもので、データをキャプチャするための最初のパスの検証に使用されます。開発では、見つかった問題を修正する必要があります。効率の問題についてのアイデアを得るために。
開発者が開発ツールをテスト環境に置くことは許可されるべきではありません。開発環境が提供するコンポーネントが欠落しているために、何かが本番環境に導入されてシステムがクラッシュするケースを見てきました。テスト環境でこの種の問題をキャッチする必要があります。
本番環境で問題が発生した場合に変更をロールバックできるように、新しいシステム バージョンの展開を計画する必要があります。
主なことは、本番サーバーの内容を正確に把握できるように、本番環境を開発からできるだけ分離することです。また、実稼働サーバーの内容を変更すると、何が変更され、その理由と、変更が実稼働環境に与える影響について、かなり良いアイデアが得られます。
これは、Mercurial や Subversion などのリポジトリの使用が品質管理の役割を担う場所です。リポジトリにあるものは、完全なパッケージとしてテストに入るという考えです。特定のパッケージのテストが完了し、品質が良好になると、パッケージは生産に入ります。
これは、本番環境のゴールド バージョンが必要な場所でもあります。安定性を確保するために、運用環境を制御された整然とした方法で変更する必要があります。以前は動作していたアプリケーションと機能がクラッシュする原因となる更新が行われるのを誰もが見たことがあるため、その更新プロセスを管理したいと考えています。
したがって、実稼働環境のゴールド バージョン (何らかのイメージ) がある場合は、それを使用して、追加のサーバー、テスト環境、デザイナー テスト環境を複製できます。本番環境の追加のバリエーションには、必要な本番環境への追加を含む独自のパッケージがあります。たとえば、開発環境は、本番環境とそのツール、デザイナー テスト データなどを含む開発環境です。
これは、仮想マシンが非常に便利な場所です。
これは面倒で非効率的に聞こえますが、実際にそうです。しかし、人は間違いを犯します。この種のプロセスは、間違いが本番環境に移行する可能性を減らすのに役立ちます。