ArcGISでPython開発プロジェクトチームとして働いていますか?


14

Python(ArcGIS 10)の開発プロジェクトがあります。このプロジェクトには、ツールボックス、マップテンプレート、レイヤーファイル、ファイルジオデータベーステンプレート(スクリプトによってマップにインポートされるテンプレートとして機能する)など、さまざまなものが混在しています。

ソースエディターとしてEclipseを使用し、ソースコードリポジトリとしてSVNを使用します。

すべてのファイル(pyファイルではない)を全員が同期プロジェクトに保持することには問題がありますが。ツールボックスは、ツールボックスを編集している複数の人によって日常的に台無しにされ、その後テンプレートファイルが調整され、チェックインされないため他の人のために更新されません。

会社のツールボックスプロジェクトに複数のpython開発者がいる組織の人々は、プロジェクトとすべての異なるファイルが正しくバージョン管理され、管理されていることをどのように保証していますか?または、すべてがEclipse(テンプレートレイヤーとスクリプトで使用されるGDBを含む)からプロジェクトに移動し、ユーザーがファイルを正しくチェックアウトすることを望んでいますか?


現在、SVNにすべてのもの(テンプレート、レイヤーファイル、ソースコード、ツールボックス)がありますか?一部の人々が適切にチェックインしていないという問題はありますか?
チャドクーパー

レイヤーファイルとテンプレートデータセットを除きます。はい、彼らは終了時にチェックインしていませんし、Eclipseでも(私が知る限り)最新バージョンに手動で更新してファイルの最新バージョン(たとえばtbx)を取得する必要があります。他の人がこれを行うためのよりスマートな方法を持っているかどうか疑問に思っていますが、私たちは現時点で試みています
ロブ

回答:


5

私が他の開発者と仕事をすることを知っているなら、私が最近する最初のことの1つは、ジェンキンスのようなContinuos統合サーバーをセットアップすることです。

チェックインのたびにテストスイートを常にトリガーし、失敗した場合はすぐに自動化された電子メールを取得するという考え方です。あなたの場合、それは単純なSeleniumスクリプトかもしれません。ブラウザー、またはArcMapを自動化するいくつかのArcObjectsスクリプトの周りをクリックします。Seleniumに関するいくつかのプレゼンテーションがあります。

Jenkinsの素晴らしい点は、他のテクノロジー(ビルドシステム、リントなど)を統合/活用できるプラグインいくつかあることです。テストでカバーされているコードの量に関するすばらしいレポートを取得できます。セットアップ本当に簡単です。

個人的に、SVNの代わりに、GitおよびGitHubと統合するのが好きです。これを行うには、認証にGitHubに依存するなど、いくつかの利点があります。

しかし、もちろん、最初のステップはJenkinsを実行することです。あなたがそれをやったことがないなら、いつか予約して、非常に風変わりなことがあるのでたくさん呼吸してください...しかし、あなたがそれを走らせたら、それは本当に素晴らしいです。


7

私がよく理解していれば、あなたの問題の1つは、開発者がSVNを適切に使用していないことです。これにより、SVNリポジトリのコンテンツが不安定になります。

したがって、いくつかのことを試すことができます。

明確なリポジトリ使用ポリシーを設定する

すべての開発者がリポジトリを使用する方法と、いつ、何をコミットするかを明確にしてください。そのため、リポジトリには常にプロジェクトの作業コピーがあります。

分散制御システムを使用する

あなたのような分散制御システムを使用する場合にGitMercurialのを各ユーザーが自分のリポジトリにコミットすることができますが、多分設定することができ、そして、彼らはそれが動作することを確認している場合にのみ集中型のいずれかにそのバージョンを送ってコミットの窓を、彼らはドンように、各ユーザのためにお互いのコードを踏まないでください。

これを言って、あなたの場合、私はMercurialに行きます。それはPythonで開発されており、あなたのニーズに合わせてフックを作成できるからです。また、SVNからの学習曲線は非常に簡単であるため、開始する良い点はhginitチュートリアルです。実際にはSVN再教育と呼ばれるセクションがあります。


2

担当者と説明責任が必要だと思います。私の提案は、ツールボックスの管理者を任命または募集することです。管理者以外は、パブリックツールボックスとそのスペース内のすべてを読み取り専用にします。管理者は、物事のテスト、チェックイン(または管理-SVNスペース外のアイテムの場合)を確実に行う責任があります。管理者は人々が何をしているのかを見る機会を得るので、誰かがいつトレーニングを必要とするか、つまり、彼は人々が不適切に物事をしているのをつかむことができます。


2

これは、テクノロジーの問題というよりも人の問題です。ツールボックスとテンプレートファイルはソース管理の外部で編集されているため、それを制御することはできません。これらのファイルはバイナリファイルであり、差分や比較ができない場合でもバージョン管理する必要があります。Thumbの一般的な規則として、コードから生成されず、コードの実行またはコンパイルに必要なものはすべて、ソース管理下に置く必要があります。

そうすれば、プロジェクト全体がソース管理下に置かれ、常に作業コピーが存在します。開発者は、ロック後にローカルバージョンのツールボックスとテンプレートを編集し、ローカルコピーが動作しているときにコミットする必要があります。

に関して

...他の人はチェックインされないため更新されません

これは人の問題であり、開発者全員がこれが重要である理由を理解しない限り、技術の量は役に立ちません。


2

ツールボックスは、ツールボックスを編集する複数の人によって日常的に台無しになります

この特定の問題のために、ツールボックスをArcSDEデータベースに配置しました。私は他の種類のデータベースを試したことはありません!2人が同じツールを同時に編集しない限り、うまく機能します。ファイルツールボックス(.tbx)を使用した場合よりも問題が少なくなります。


複数の人が異なるツールを同時に編集できるように、SDEでツールボックスをバージョン管理すると言っていますか?このアプローチに問題はありませんか?
シンディジャヤクマー

いいえ、ツールボックスをバージョン管理できるとは思いません。SDEでツールボックスを作成するだけです。また、複数のユーザーが異なるツールを同時に編集できます。2つの問題、明らかに誰かが同じツールを編集し、ArcToolboxがツールボックス(SDE)の開始時にコンテンツをロードしてメモリに保持する場合、誰かがツールボックス(SDE)の開始以降に編集されたツールを開く場合。後者は既知であるかのように最小化でき、ArcMapを再作成するか、SDE接続を閉じて再度開くことができます。これが明確であることを願っています。
jeb
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.