問題タブ [configuration-management]

dotnet プロジェクトのセットアップ方法の例はたくさんありますが、私たちの状況に合うものはありませんでした。

複数のアプリケーションと複数の依存関係を持つ 1 つのソリューションがあります。私たちは現在 SourceSafe を使用しており、Subversion に移行する予定ですが、ソースを正しい方法で編成するのが難しいと感じています。

• 解決例

  • アプリ1
  • アプリ2
  • ビジネスオブジェクト
  • データアクセス
  • カスタムコントロール

• 依存関係

  • BizObjects->DataAccess
  • App1->CustomControls
  • App1->BizObjects
  • App1->DataAccess
  • App2->CustomControls
  • App2->BizObjects

また、オペレーターが作業しているワークロードに応じて (データベースからのコピーを介して) 展開する構成管理システムもあります。バージョンでアプリケーションの「リリース」をマークし、そのリリースに複数のファイル依存関係を追加します。現在実施しているソリューションは、古い (Windows 3.1 で開発された) ソリューションを .NET ファイル/依存関係構造で動作させるための応急処置であることに注意してください。

App1 の場合、App1.exe、BizObjects.dll、DataAccess.dll、および CustomControls.dll があります。BizObjects が DataAccess を参照しているため、App2 にも同じ一連の依存関係がありますが、これは手動で定義されています。依存関係ツリーを識別するためのシステムが整っていません。

「リリース」の各依存関係は、ファイルとバージョン ID です。また、同じアプリケーションに、ワークロードごとに異なるバージョンの各ファイルを含めることができます。

1. 世界のどこで私たちは間違っていたのでしょうか? 私たちは間違っていましたか？
2. 展開要件に対応するために、svn ソース ツリーをどのように構築できますか?
   • また
3. セットアップに適した展開戦略をより適切にサポートするために、コードを再構築するにはどうすればよいでしょうか?

比較的単純な問題 (と思われる) に対して、古くて過度に設計されたソリューションがあります。誰かが私/私たちを正しい方向に導くことができますか?

編集:私はこの質問を読み、コードが通過しなければならない同じ開発/テスト/製品領域もあることに気付きました。

私が現在働いている組織は、すべてを文書化する CMMI の世界全体に移行しようとしています。私は (他の 1 人と一緒に) 構成マネージャーの役​​職を割り当てられました。おめでとうございます。

職務の一部は、物理的な構成監査を定期的に実行することです (彼らはまだ定期的に定義していますが、四半期ごとまたは毎月のいずれかになります)。これは基本的に、本番環境にデプロイされたソース コード バージョンと、本番環境のソース コード バージョンであると思われるバージョンのチェックです。

私たちのプロジェクトは、Java で書かれた比較的小さな Web アプリケーションです。扱うファイルの種類は、java、jsp、xml、プロパティ ファイル、および sql パッケージです。

私が抱えている (そして表明したが無視されているように見える) 問題は、実稼働サーバーに物理的にログオンしてファイルのバージョンを確認するにはどうすればよいかということです。

ファイルのバージョンは、現在、ファイル (つまり、コメントなど) にも含まれていません。ユーザーにも表示される各画面に表示可能なバージョン番号を配置することが提案されました。画面自体は私たちが管理しているコードのごく一部にすぎないので、これもばかげていると思いました。

現在使用しているツールは、IDE 用の Netbeans とバージョン管理ツールとしての Serena Dimensions です。

私は特に、正確で時間がかからない、より自動化された方法でこの監査を実行する方法についてのアイデアを探しています.

私の考えは、現在、そのファイルのバージョン番号を含む各ファイルの先頭にコメントを追加することです.XMLファイルを作成するために本番ビルドが作成されるときに実行されるスクリプト、またはそれぞれのファイル名とバージョンファイルを含む同様のものを作成しますビルド内のファイル。次に、監査を行う必要がある場合は、実稼働サーバーに移動して情報を含む xml ファイルを取得し、それを実稼働にあると思われるものとプログラムで比較し、レポートを出力します。

より良いアイデア。私はこれがすでに行われている必要があることを知っており、他のリソースが見つからないことに気が狂っているようです.

同じソース コードから構築された 3 つの密接に関連するアプリケーションがあります。たとえば、APP_A、APP_B、および APP_C とします。APP_C は、APP_A のスーパーセットである APP_B のスーパーセットです。

これまでのところ、ビルドするアプリケーションを指定するためにプリプロセッサの定義を使用してきました。これは次のように機能します。

私のIDEビルドオプションは、次に指定します（たとえば）

...そしてソースコードには、次のようなものがあります

しかし、私は今朝自分の足を撃ち、1 つのファイルから #include "app_defines.h" の行を省略しただけで、非常に多くの時間を無駄にしました。すべてが正常にコンパイルされましたが、アプリケーションは起動時に AV でクラッシュしました。

これを処理するためのより良い方法が何であるかを知りたいです。以前は、これは通常、#define を (C++ で) 使用できると考える数少ないケースの 1 つでしたが、それでもひどく間抜けで、コンパイラは私を保護しませんでした。

私の会社で行っている作業の一部は、同じファミリ内の異なる製品と各製品の異なるフレーバー (または機能セット) を持つ製品ファミリに向かってゆっくりと進んでいます。私たちに役立つかもしれない製品ラインのエンジニアリング技術を探しています。Web 検索は、多くのリソース、さまざまな情報源、さまざまな方法論につながります。これらのいずれかを詳細に説明する前に、これと似たようなことを以前に行ったことのある人から実用的なアドバイスを得ることが役立つと思いました. 誰もがこの分野での指針/知恵のナゲットを持っていますか? 私は特に、製品ライン環境で次のことを行うためのより良い方法を探しています。

1. 構成とビルド管理
2. 開発サイクルの容易さ
3. テスト

英国の VAT システムは 17.5% から 15% に変更されます。VAT を格納するためにコードで使用した戦略と、変更がアプリケーションに与える影響。古い価格を計算できるように vats の履歴を保存していますか、それとも古い請求書を別のテーブルに保存していますか? それは単純な構成設定ですか、それとも邪魔しましたか? VAT を保存する理想的な方法は何ですか?

リリース管理のトピックについては、私が知る限り、基本的に WSUS が提供する機能 (リモート インストール、バージョン クエリ、マシン/グループごとの設定など) を実行するソフトウェアのオプションを調査していますが、私のカスタムについてはソフトウェア。また、サードパーティの実行可能ファイル (グラフィックス ドライバー インストーラーなど) を実行したり、更新前にソフトウェアが現在実行されているかどうかを通知したりできる必要もあります。

更新: インストールする C#/C++.NET コードを主に検討していますが、更新を 1 つのサーバーから多数のクライアントに同時にプッシュするためのソリューションを探しています。それは、たとえば NSIS インストーラーのビルド スクリプトなどをラップする必要があるものですか、それとも、ハイブリッドの管理/管理/インストール ツールはありますか? 私は現在、ギャップを埋めるためのある種のスクリプトを使用して、NSIS/WiX を主な候補として検討しています (そのための言語に関するアドバイスも? Windows PowerShell?)。

ドキュメンテーションは開発者の好みの分野ではありませんが、組織内に標準を持ちたい場合は満たすべき重要な分野です。私たちは、開発、ステージングから本番までのプロセスなど、変更管理、バックアップ戦略、およびその他の楽しいことをセットアップするために、新しい構成管理計画をまとめようとしています。

良い例について、またはおそらく CMP プロセスの良いスタートについて、ご意見をお聞かせください。

構成設定の保存に関するいくつかのベストプラクティスについて疑問に思っています。いくつかの設定を複数のアプリケーションで共有しているとします。共有する必要があるこれらの種類の設定 (XML ファイル) を保存する良い方法と悪い方法の両方を聞いたことがあります。

展開を容易にするためにビルド間でアプリの設定を維持するという点で、適切な標準は何かを考えてみてください。

私は2つのシナリオからこれを見ていると思います:

1. 社内のアプリケーション (.com の大規模な管理アプリでも小規模な管理アプリでも)。
2. 他のユーザーが使用する API を作成するとき、アプリケーションで API を使用するコンシューマーからの最終的な値がわからない場合に構成設定を参照する方法。

追加-1 :

ありがとう。複数のアプリケーションにまたがる構成設定を管理する悪夢を抱えている場所があるという恐ろしい話を聞いたことがあります。私はビルド担当者ではないので、理由はわかりませんが、web.config とカスタム構成ファイルなどのシナリオの種類に関して、今理解していることを確実に確認したいと思います。

追加-2 :

また、使用する API を作成する場合はどうでしょう。特定の構成情報を取得しようとしているクラスがあるとしましょうが、クライアントが API (具体的には C#/.NET) を使用するまで、それらのエンドポイント (プロパティ) は定義されませんか? これらのプロパティをどこでどのように設定しますか?たとえば、「ApplicationDefinitions」などの構成クラスを作成しますか?

一般的な J2EE Web アプリケーションの場合、データソース接続設定はアプリケーション サーバー構成の一部として保存されます。

これらの構成の詳細をバージョン管理する方法はありますか? データソースやその他のアプリケーション サーバー構成の変更をより詳細に制御したい。

これを行うための標準的な方法は何ですか?

プロジェクトAとBがあります。どちらのプロジェクトもコンポーネントC（たとえばグラフィカルライブラリ）を使用しています。Aにバグがあることを報告する発行チケットを受け取ります。本当にバグはCコンポーネントにあると思います。Cのブランチを作成し、修正し、チェックインし、タグを付け直し、Aの依存関係を変更して、新しいAインストールを作成します。

質問：BにCコンポーネントの変更を認識させて、Aで検出されたバグ修正の恩恵を受けるにはどうすればよいですか？このような構成管理シナリオを制御するための優れたツール/スクリプトは何でしょうか。Jiraを試してみましたが、2つのプロジェクトを1つ以上のコンポーネントに依存させる良い方法を見つけることができませんでした。