ソースコードと同様の規律を持つビジネスレベルの構成のバグを防ぐにはどうすればよいですか？
オーダー作成から45分以内に食料品を配達できるように、お客様（買い物客）を調整できるシステムがあります。
各クライアントには、注文が買い物客によって処理される一連のストアがあります。
そして各買い物客は、どの店で何時に働くかを指定するスケジュールを持っています。
ただし、システムにストアがすでに構成されており、注文を配送する予定の買い物客が十分にいる場合にのみ、注文を作成できる機能もあります。
ご覧のとおり、特定の注文がシステムで受け入れられるかどうかの確認は、現在の時刻、店舗の構成、および買い物客のスケジュールによって異なります。
私たちはソースコードの管理にかなりの仕事をし、コードレビュー、ユニットテスト、統合テストを行っています。しかし、ストアとスケジュールの構成を管理する満足な方法が見つかりませんでしたソースコードと同じくらい敏感です間違った構成がある場合、クライアントにとってはほぼ同じです注文の作成を許可せず、売上が減少するため、ソースコードにバグがあるかのように。
したがって、ストアの構成とスケジュールを、ソースコードで行うのと同じような規律で管理する方法を見つけたいと思います。構成が正しいかどうかをテストする方法が必要です。現在、テスト可能なSQLスクリプトを介してこの構成を行っていますが、inputsは正しくない可能性があり、それらを管理したり、正しいかどうかをテストしたりする方法はありません。
同様の問題がありましたか？クライアントの構成を間違えないようにするツール、言語、プロセスを知っていますか？データベーステーブルを見る以外に、実際の構成を一元的に把握する方法がありますか？
ちなみに、クライアントと話すビジネスマンからこれらの設定をスプレッドシートとして受け取ります。
ソフトウェアの鉄則は：
ガベージイン、ガベージアウト
この厳しい現実に対処するには、発見した要件に対処する必要があります。
構成プロセス
構成プロセスは、システム展開の準備作業です。信頼性と再現性が必要な場合は、構成ジェネレーターを使用して自動化します。このソフトウェアは、コアソフトウェアがビジネスプロセスをサポートするのと同じくらい真剣に構成プロセスをサポートします。
有効な構成の要件と、入力データがそれらに与える影響を分析します。次に、手動でエラーが発生しやすいこれらの展開アクティビティを確実に自動化するジェネレータを設計します。最終的にExcelを適切な構成アシスタントに置き換えて、データ入力でオペレーターをガイドします。
好奇心のために：システム構成は、80年代の ルールベースのエキスパートシステム の最初の実際の使用の1つでした。しかし、あなたのニーズは必ずしもそのような高度なエンジンを必要としないでしょう;-）
スケジュール
スケジュールはビジネスデータのようです。ビジネスアクターは、ビジネスの現実に基づいてこれらを変更できる必要があります。そして、間違ったデータや間違った決定はビジネスの現実です。
一部のスケジュールが顧客のプロセスにリスクをもたらす可能性がある場合（たとえば、他のルールにより配信が妨げられるため）、ビジネス要件はそのようなリスクを防ぐ必要があります。たとえば、データ入力の時点で担当の事業者に通知したり、潜在的なリスクの検証をスケジュールしたりします。
一部のスロットに十分な買い物客がいないことを担当ビジネスアクターが認識するとすぐに、データの不整合の問題ではなく、ビジネスアクタが対処する必要があるビジネスの現実（この例では、スタッフの強化） ）。
結論
あなたはビジネスニーズに対処するための強力な開発プロセスを持っているようです。 DevOps の精神で、範囲を拡大し、展開と運用の要件も含めるときがきたのかもしれません。
あなたが書いた
コードレビュー、ユニットテスト、統合テストを行います
（そして、私はあなたがソース管理も使用していると思います）。これらの手法はすべて、構成ファイル（またはスケジュール）にも適用できます-少なくとも同等の方法で：
ソース管理=必要に応じて詳細な変更ログと「diffツール」を使用した、構成ファイルの適切なバージョン管理。これらのファイルを管理する人が開発チームと同じSVCSツールを使用する必要はありません。必要に応じて、手動で、またはZipファイルやDMSを使用してバージョン管理を行うこともできます。
コードレビュー= 2人目の校正刷り。実際には、「校正」という用語は「コードレビュー」よりもはるかに古くなっていますが、本質的には同じものです。
ユニットテスト-これは構成ファイルに100％マッピングされない場合がありますが、システムのどこかに構成パラメーターまたはルールの少なくともいくつかの健全性チェックがあり、構成が構文的に間違っているか一貫性がない場合に詳細なエラーメッセージが生成されます。
統合テスト-これはおそらく最大の課題です。 1つのアプローチは、実際には他の場所でのソフトウェアとの統合テストに必要なものと変わりません。新しい構成をほぼ実際のデータで、おそらく手動で、あるいは自動的にテストできるテスト環境です。別のアプローチは、「ドライラン」のようなものを本番システムに実装することです。そのため、ビジネスマンが構成ファイルを変更した場合、実際のデータを実際に変更せずに、ライブシステムでテストする機会を得ます。
ご覧のとおり、特別な「新しいツール」は必要ありません。品質保証のすべての通常の方法を構成ファイルにも適用できます。あなたはそれらを適用するように人々を説得する必要があります。
一部の人々はこれを理解していませんが、構成の処理はそれ自体のソフトウェアの問題であり、設計の一連の課題があります。悲しいことに、あなたのソフトウェアはあなたの会社に固有なので、あなたの会社はあなたのソフトウェアのためにツールを作ることができる唯一のものです。
バックオフィスの必要性が生じます。最初は、それは単にビジネスの人々が固定形式のスプレッドシートをアップロードできる内部Webインターフェースにすることができます。バックエンドはそれをDBに挿入する前にいくつかの基本的なチェックを行い、エラーを発生させて、ビジネスマンが何が壊れているかを修正することができます。セットアップは簡単で、すぐに始めることができますが、使い勝手がよくないため、構成が複雑な場合は、入力に時間がかかります。
長期的に見ると、本当に必要なのは、リアルタイムの検証機能を備えた独自のWebベースの構成エディターを用意することです。そこに到着したら、バックオフィスをクライアントの手に渡して、構成を直接入力できます。これにより、構成がより堅牢になるだけでなく、エクスペリエンスが大幅に向上します。それは開発コストに関連する選択かもしれませんが、あなたの会社がこれを予期していなかったのは驚くべきことです。