問題タブ [configuration-management]

現在、静的テキストを構成可能にする必要があるプロジェクトに取り組んでいます (ラベル、メッセージ、および検証エラーを含む)。最善のアプローチは何だろうと考えていました。このアプリは、ASP.NET MVC と C# 3.5 を使用して作成されています。このすべての静的な構成可能なテキストを、別のプロジェクトから MVC プロジェクトに供給する必要があります。グローバル リソースを使用するか、アプリケーションの起動時に読み込まれる XML ファイルを使用することを考えました。ところで、これはローカリゼーションに関するものではありません。また、エンドユーザーが静的テキストを構成することもできません。

サードパーティのライブラリをソース管理に保存する方法を尋ねる投稿があることは知っています ( thisやthisなど)。これらは素晴らしい答えですが、私はまだこれに対する答えを見つけることができません:

ライブラリが適切に動作するためにコンパイラ/IDE を変更する必要があるサードパーティのミドルウェア/フレームワーク バイナリをどのように保存しますか? 注: 必要に応じて、ミドルウェア ソースを保存する必要はありません。ヘッダー ファイル / lib / JAR のみを保存して、リンクする準備ができているようにします。

通常、ライブラリをアプリにリンクするだけで問題ありません。しかし、さらに必要なミドルウェア/フレームワークについてはどうでしょうか?

具体例:

• Qt moc プリプロセッサ。

• ZeroC Ice Slice (ice) コンパイラ (CORBA IDL プリプロセッサに類似)。

基本的に、これらのフレームワーク/ミドルウェアは、アプリケーションがリンクする前に独自のコードを生成する必要があります。

開発者の観点からは、理想的には、チェックアウトするだけで、すべての準備が整っている必要があります。しかし、私のIDE/コンパイラはまだ適切にセットアップされていないため、コンパイルは失敗します..

どう思いますか？

構成管理とバージョン管理の違いを簡単に説明できますか？さまざまなWebサイトで見つけた説明から、構成管理は、構成ファイルをソース管理リポジトリに配置するための単なる空想用語のようです。しかし、他の人は私にもっと複雑な説明があると信じさせます。

真の開発と展開のメンテナンスのために、CI サーバーと構成管理ツールを一緒に使用する必要があります。

事実上のレールの持続可能な環境はありませんよね？

いくつかの仮定:

• コード管理バージョン OK - git (デファクト ツール)
• テスト フレームワーク OK - 何でも (rspec を選択)
• コード カバレッジと分析 OK - 何でも (metric-fu など)
• サーバー スタック OK - (Passenger など)
• イシュー トラッカー (RedMine)
• その他 ...

整合性と密造酒のプロジェクトがあればプレイしたいのですが、私にとっては始めに適していますね。

これについてあなたはどう思いますか？

ありがとう、

ブルーノ

2週間前、パスワードを使用してアプリケーションの構成をコミットしましたが、あまり役に立ちません。コミット履歴からファイルを削除して、再コミットされないようにするにはどうすればよいですか？

パスワードが含まれているため、すべてのコミットツリーからファイルを削除したいと思います。

私はSubversionの慣行について経営陣と話し合っています。校正を見逃した場合に備えて、後でコミットコメントを変更できるように、管理者にSubversionリポジトリを構成するように依頼しました:-)。

私の議論は、

• より広範なコメントや間違ったスペルなど、改善が必要なログメッセージは変更できます。
• ログメッセージを入力するときに間違いが簡単に発生するため、元に戻すことができます。
• 間違いがあったとき、誰もが二度目のチャンスに値する:-)
• ソースコードとコメントをリポジトリからサードパーティにエクスポートする場合、誤ったログメッセージが見つかった場合に役立ちます。コメントを変更できない場合、またはエクスポートされたテキストファイルでのみ変更できる場合は、すべてが非同期になります。

短所は、

• ログメッセージの変更自体は検証されないため、古いメッセージは明らかに失われます。

私たちの経営陣は、「管理コストの増加」と「後で変更できるリスクが高い」という理由で、私の変更要求を拒否しました。明らかに、私はより広範な説明を求めてきました。

とにかく、皆さんはこれについて何かコメントがありますか？どう思いますか？後でログメッセージを編集しても大丈夫ですか？経営陣に伝えるために、これ以上プロを教えてもらえますか。

これは開発者の自由を制限すると思います、そして私が開発者として私は最大の自由が繁栄することを望んでいます:-)

私たちはゼロから始める小さなスタートアップ企業です。Subversion を使用しており、リポジトリは Web ベースのサービスにあります。

私は CVS に精通しており、SVN の紹介を読みましたが、大したことではありません。CM 自体に費やす労力を最小限に抑えながら、競合することなくスムーズに作業できるようにするCM方法論への言及に興味があります。車輪を再発明する必要はないと確信しています。自分の考えを確認したいだけです。

私が考えていることは次のとおりです。

• 各開発者は自分のプライベート開発ブランチを開始します
• 完了すると、統合ブランチにマージされます。統合ブランチでさらなる安定化が行われます。
• 統合が完了すると、トランクにマージされ、タグが付けられます。

私は不明です：

• その後、トランクから新しいプライベート ブランチを開始する必要がありますか、それとも同じプライベート開発ブランチで作業を続ける必要がありますか?
• 特にトランクに再統合すると、svn が特別な動作をすることがわかります。それでは、特別な統合ブランチを持つことには利点 (または欠点) がありますか?

どうもありがとう。

.hg/、.hgignore、.hgtags などを除く、リポジトリのルート フォルダーの下にあるすべてのファイルが必要です。これを行うための Mercurial 組み込みまたは既存の拡張機能はありますか?

ハードコードされた「mercurial ファイル」を含む非 hg スクリプトを実装しましたが、mercurial 関連ファイルを除外するプログラムによる方法が必要です。

すべてのファイルを定期的に削除し、Starteam からクリーン チェックアウトを実行してから、hg addremove を実行してからチェックインすることにより、Mercurial 以外の構成管理サーバー (Starteam) をミラーリングしようとしています。

チケットシステムとしてJIRAを使用しています。新しいバグ/チケットがそのシステムに送信されます。バグが修正されたら、新しいビルドを作成し、開発サーバーでテストします。すべてが良好であれば、ライブサーバーにプッシュします。現在、私は通常、バグを修正するために分岐せずにトランクで作業しています。もちろんこれは問題です。私たちのシステムには多くのバグがある可能性がありますが、一度に修正されるのは特定のバグだけだからです。ただし、ブランチではなくトランクですべてを修正すると、すべてをテストするのに十分な時間がなかったとしても、すべてをテストする必要があります。通常、バグやブランチなどをどのように修正しますか？（私がそれを非常にうまく説明したかどうかはわかりません）。