問題タブ [configuration-management]

CSCI / 構成アイテムの最も公式な定義を探しています。それが何であるかだけでなく、構成アイテムとして開発されるサブシステムを契約で定義するときに提供する必要がある/期待できるものです。

私は有名な検索ツールで時間を費やし、CSCI (ウィキペディア、頭字語のディレクトリなど) に関する多くの説明を見つけましたが、標準または標準へのポインター (ISO-xxx など) をまだ見つけていません。 (1) それは何か、(2) QM/CM の観点から何をしなければならないか。

請負業者の QM 担当者が受け入れテスト中に述べたので、CI は構成計画の CI を忘れずにシリアル番号を割り当てることだけが必要であると述べたので、私はただ尋ねます... SRS、SDD、ICD、SVD、 SIP、... ドキュメント、およびそれらのサブシステムの受け入れテスト ドキュメント...

トランクが「メイン」ブランチであることを理解し、ブランチとタグの概念を理解しています。しかし、「頭」はどこに登場するのでしょうか。「最新の」リビジョンのようですか？もしそうなら、それは「トランク」との違いです

私はおそらく無関係なフィールドを混合していると確信しています。たとえば、トランクは分岐し、ヘッドはタグになりますか？

私はいくつかのドキュメントを掘り下げましたが、時間制限がそれほど明確ではなかったことを認めなければなりません。

XMLファイルを含むzipファイルとして作成された一連のファイルをソース管理したいと思います。

現在、これらのファイルはそのままチェックインされているため、すべての明らかな制限があるバイナリファイルとして扱われます。

これらのファイルにはXMLファイルが含まれているため、プログラマーにzip / unzipを要求しないように、次のことを自動的に実行したいと思います。

チェックインの場合：ファイルを自動的に分解します：

• これらのファイルには固有の拡張子があるため、その拡張子でチェックインされたファイルごとに
• そのファイルをメモリ/一時的な場所に解凍します
• それらのファイル（XML）ごとに、それらを正規化します（比較/マージ用）
  • ルートの直接の子ノードを事前定義された順序で並べ替えます（アルファベット順など）
  • 一部のアイテムにはローカル参照IDがあり、並べ替え後にIDを順番に書き換えます。
• 元のzipファイルと同じ名前でSVNにフォルダーを作成します
• zip内のファイルをそのフォルダーにチェックインします

チェックアウトの場合：ファイルを自動的に再パッケージ化します。

• 重要性は低い-Maven/Antを使用して実行できます
• 展開されたフォルダ（またはそのコンテンツファイルのいずれか）をチェックアウトするとき
• そのフォルダ/ファイルをチェックアウトする代わりに：
• そのフォルダ上のすべてのファイルを圧縮します
• そしてzipファイルをチェックしてください

マージの場合

マージはSVNサーバー側ではなく、クライアントの責任であると思います。そのため、代わりにマージプラグインを作成する簡単な方法があります（Tortoiseなど）。

上記のいずれかが可能ですか？もしそうなら、どのように？複数の方法がありますか？

SVN で次の一般的な StarTeam タスクを実行する方法を知りたいです。

1. タグを更新して、1 つのファイルだけの新しいリビジョンを含めるにはどうすればよいですか?

StarTeam でビュー ラベルを作成した後(SVN のタグに似ています) - ファイルの新しいリビジョンをそのビュー ラベルに含めることができました。そのビュー ラベルの作成

2. 別のタグに基づいてタグを作成する方法は?

バージョンをリリースしながら開発を続けると、チェックインされていても含まれない機能もあります。StarTeam では、以前のビューに基づいてビュー ラベル (タグのようなもの) を作成していました (そして、説明したことを実行します)。質問1）で。SVN では、別のタグに基づいてタグを作成できることを理解していますが、それは読み取り専用であり、ブランチが必要です。しかし、本当にブランチは必要ありません。

3. 既存のタグにチェックイン/追加する方法は?

StarTeam では、ビュー ラベルはトランク/ブランチ上にあるため、ビューが作成された後にファイルをチェックインし、それを含めるようにラベルを変更できます。SVN では、ブランチにチェックインする必要があります。

いくつかの既存のインフラストラクチャ アセンブリを既存のアプリケーションと共有し、既存のドメイン モデルの重要なサブセットも含む、新しいアプリケーションのプロトタイプ作成を開始しようとしています。

ドメインモデルの一部は、この新しいアプリケーションのためにいくつかの重大な変更を受ける可能性があり、新しいアプリケーションが完全に仕様化され、ローンチの準備が整ったら、これらすべての最終的なゲームは、 2 つのアプリケーション (データベース、リンク機能などを共有するだけでなく) を使用しますが、開発やプロトタイピングなどの期間中は、別のデータベースを使用して、開発や使用への影響を心配することなく物事を変更できるようにします。既存のアプリケーション。これはプロトタイプであるため、さまざまなワークフローを使用した製品管理の実験、さまざまな顧客ベースの調査など、深刻な変更や再構築が発生する可能性があるかなり長い期間があり、私たちはそれに追いつくよう努めています.

成熟したアプリケーションでの並行開発に影響を与えないように、既に Subversion ブランチを作成しており、これを進めるための 2 つの方法を試しています。

1. 分離の唯一のメカニズムとして svn ブランチを使用します。既存のドメイン モデルに変更を加え、既存のアプリケーションへの影響を評価します (また、ProjectA に必要な変更を加えます)。長期にわたって実行されているサイド ブランチが、トランクに再エントリするのに十分安定していることを確認します。

2. 共有コードを (一時的に) "フォーク": ProjectA.Entities を NewProject.Entities にコピーし、すべての NewProject コードを自己完結型として扱います。モデルに関するすべての混乱が収まり、私たちが満足していると感じたら、手動で変更を ProjectA.Entities に再統合し (必要に応じて粒度またはスイープとして)、各ステップで改善されたモデルを使用するように ProjectA を更新します (これには時間がかかる場合があります)。サブバージョンのマージが発生する前または後に配置します)。Subversion マージは、ここでの大きな変更の再結合を処理しません。注: 「フォーク」メソッドは、大幅な変更が保存されているコードにのみ適用され、その変更により ProjectA が壊れます。たとえば、共有インフラストラクチャのものは、その場で (ブランチで) 変更し、マージを整理します。 .

3. 開発は難しい、買い物に行く。

当然、合意に達しなかった後は、SOである力のオラクルに任せています。これらの方法のいずれかの経験、注意すべき問題点、まったく新しいことはありますか?

* nix worldが持っているようなウィンドウ用のツールはありますか？ChefやPuppetのようなものを探しています。

私はcfEngineを見つけましたが、それでも非常に*nix中心に見えます。理想的には、オープンソースであり、コマンドライン駆動型です。

アイデアは、自動化されたインフラストラクチャとWindowsベースのサーバーを組み合わせることです。現在のIT部門では、Windows以外のサーバーは許可されていません。

.NET で作業する場合、web.config または app.config を使用して複数の環境 (開発、テスト、運用) をセットアップできます。

たとえば、Web (安静) サービスの場所を指定して、あるサービスに対して開発し、別のサービスに対してテストしてから、アプリのリリース バージョンで運用 URL を使用したいと考えています。

Androidで同様のことを行うにはどうすればよいですか?

編集:バージョンをリリースするたびにURLを変更せずに

私たちはC++プログラムを書いていますが、それは（開始時に）高度に構成可能である必要があります。現在、いくつかの構成変数を含むベースXMLファイルと、より多くの構成変数を含む他のXMLファイルのファイル名があります。全体として、約10個のXMLファイルのツリーと、他のコンテンツを含むいくつかのバイナリファイル形式があります。

現在、非常に厄介になっています。ファイルは相互にリンクされているため、実際に解析されるファイル、編集する必要のある構成、または設定するパスを見つけるのは困難です。

相互リンクされたXMLファイルを除いて、複雑なソフトウェアの構成を実装するためのより良い方法はありますか？

私が緩めたくないこのアプローチの利点の1つは、構成のある部分から別の部分への切り替えが比較的簡単なことです。たとえば、2つの異なるロボット用に2つの構成ファイルがあり、使用しているロボットを切り替えるには、ベースXMLファイルから正しいファイルをリンクするだけです。

編集 いくつかの考えられるアイデアは次のとおりです。

• データベースの使用に切り替えますか？これは高度に構成可能ですが、人間が読める形式ではありません。
• Firefoxのようないくつかの構造about:config？
• 1つの巨大なフラットな.iniファイルで、コピーを処理するだけですか？オプションではありません、これはさらに面倒です
• ..。

いくつかのサードパーティ ライブラリ (logging、orm、di など) を使用して新しいプロジェクトを開始しようとしている場合、流暢なインターフェイスまたは XML ファイルを使用してプログラミングすることで、これらすべてのライブラリを構成することを希望しますか?

これらのオプション (Fluent または XML) の 1 つだけをサポートするライブラリを使用しますか? それとも、さまざまな構成戦略から選択できるライブラリを好みますか。

コードが好きな人は、これを架空の例 (C# で記述) と考えてください。

これは流暢な構成です:

これは XML 構成です。

最後に、Fluent と XML 構成の長所と短所は何ですか?

これまでのところ、次のようになりました。

コードでの流暢な構成

長所

• コンパイラによって評価された強く型付けされた
• 条件付き構成

短所

• ビルド後に再構成できません

XML 構成

長所

• デプロイ後に簡単に変更可能

短所

• XML は冗長です
• 入力ミスが起こりやすい

私の友人と私は、Eclipse IDE 3.6 - Win 7 オペレーティング システムでの Android アプリ開発に同時に取り組んでいます。

最適な ClearCase ツールはどれですか?インストールして Eclipse に統合するための詳細な手順を教えてください。