web-dev-qa-db-ja.com

ソフトウェアプラットフォームを管理するためのソース管理ワークフロー

私は、クライアントにさまざまなプロジェクトを提供するために使用される、Cで記述されたソフトウェアプラットフォームを担当しています。私はこのプラットフォームを使用している人々のワークフローを改善しようとしています。そして、ソースコード管理（Mercurialが最も可能性の高い候補）が役立つかどうかを調べています。

プラットフォームは、内部で年間最大10プロジェクトのみ使用されます。幅広い機能と、ほとんどのプロジェクトで使用されていない多くのビットがあります。その結果、たくさんのバグが隠されています。

このように絶えず更新されるプラットフォームを管理または使用して、誰かが同様の経験を持っているかどうか疑問に思います。

現状

プラットフォームの開発はMercurialリポジトリを使用して行われますが、プラットフォームのリリースはMercurialを介して行われません。リリースの場合、プラットフォームファイルは中央サーバーのtarballに配置されます。コアに接続されているシステムの場合、ビルドプロセスの開始により、更新されたtarballがコピーされ、アプリケーションのソースコードに解凍されます。アプリケーションプログラマーはコアファイルを編集できません（さまざまなコマンドがシェルスクリプトを介してエイリアス化され、試行するとエラーが発生します）。

私が求めているもの

どういうわけかMercurialを使ってこれを管理することは可能であるように思われます。プラットフォームのリリースブランチを簡単に維持し、プロジェクトにリリースブランチを開始点として複製させることができます。

しかし、その後どこに行くのかはわかりません。プロジェクトでは、機能は完全にクライアント次第です。コアファイルのロックが解除されると、より良い方法がある場合でも、人々はすぐにそれらの編集を開始します（これはロックダウンの前に起こったことです）。これは、新しいコアの変更をマージすることが難しくなることを意味し、多くのチームが気にしない結果になると思います。

コアファイルをロックし、すべてのプロジェクトに自動更新を強制するという厳格なソリューションは、非常に成功しました。強制更新を受信するプロジェクトよりも、切断されたプロジェクトから多くの苦情や問題が発生します。ただし、プロジェクトがテストに入るとすぐに、プロジェクトを切断する必要があります。その後、手動でマージしない限り、プラットフォームの更新は行われません。

cversion-controlmercurialplatforms
3
asc99c

commit-approval のさまざまなフレーバーで同様の問題に対処しました。さらに、 ACL （および場合によってはセキュリティが必要な場合） CheckGpgSig を使用します。

セットアップするプロジェクトごとに、セットアップを使用するように強制します。（csh | sh）スクリプトは、必要に応じて（1）警告するか（2）ツリーを更新するように促します。

2
synthesizerpatel

私もMercurialユーザーではありませんが、Subversionユーザー（私のような）が「外部」と呼んでいるようなもの、つまり共有ライブラリ（「プラットフォーム/コア」）を別のプロジェクトにプルする可能性を求めているようです。異なるリポジトリに存在する可能性があります。同じ機能を提供するMercurial拡張機能へのリンクは次のとおりです

http://Mercurial.selenic.com/wiki/HgExternals

「Mercurialexternals」をグーグルで検索すると、さらにいくつかのリンクが表示されます。

「外部」機能を使用すると、

  • プロジェクトで使用するライブラリのリビジョンを正確に定義します。 libの新しいリビジョンがチェックインされた場合でも、すぐに使用する必要はありません。
  • 使用中のプロジェクトからリポジトリに直接コミットされるライブラリへの変更を防止します

もちろん、特定のバージョン管理システムとは別に、できることがいくつかあります。

Libのユーザーにソースコードを編集させたくない場合は、「バイナリのみ」のバージョンを提供してみませんか？これは、彼らが「コア」を編集するのを防ぐ非常に効果的な方法です。それが不可能な場合は、すべてのソースファイルに「編集しないでください」という免責事項を追加することができます。実際、誰もがそのコメントを無視することができますが、そうすればあなたが援助を拒否するのがより簡単になります。

一方、実際にlibの（一部の）ユーザーにlibのソースコードを編集してもらいたい場合は、tarballを与えるのではなく、リポジトリに特別なブランチを作成する必要があります。このようにして、後で変更をマージするのがはるかに簡単になります。

もう1つ、プラットフォームの自動テスト（ユニットテストと統合テスト）はありますか？それはあなたの状況で非常に（！）役立つかもしれません。プラットフォームのトランクに何かをマージして戻す前に、これらのテストを実行して、プラットフォームのユーザーが最新リリースに更新したときに悪い驚きを感じないことを確認できます。

1
Doc Brown

私はMercurialやSubrepositoriesの第一人者ではありませんが、あなたの仕事ではサブリポジトリ（ Aragost Kick-start と Wiki ）を使用できると思います。

つまり：

  • （別の？）レポにプラットフォームがあります
  • （直接コピーではなく）サブリポジトリとしてすべてのプロジェクトにリンクします

このようにして

  • プロジェクトへのリリースの簡単な公開（サブリポジトリを必要なcsetに更新し、メインリポジトリにコミットします）
  • プラットフォームコードは効果的にロックされています（プロジェクト開発者がリモートプラットフォームリポジトリにプッシュする権限を持っていない場合、変更してコミットすることはできません）-TBT !!!
1
Lazy Badger