ArcGIS ile Python Geliştirme Proje Ekibi olarak mı çalışıyorsunuz?


14

Python'da (ArcGIS 10) bir geliştirme projemiz var. Bu proje, araç kutuları, harita şablonları, katman dosyaları, dosya coğrafi veritabanı şablonları (komut dosyaları tarafından bir haritaya içe aktarılan şablonlar gibi davranır) ve diğer çeşitli şeyleri içerir.

Eclipse'i kaynak editörümüz ve SVN'yi Kaynak Kodu Depomuz olarak kullanıyoruz.

Tüm dosyaları (py dosyaları olmayan) herkes tarafından senkronize bir projede tutmakla ilgili bir sorunumuz var. Araç kutusu, araç kutusunu düzenleyen birden fazla kişi tarafından rutin olarak dağıtılır ve daha sonra teslim edilmediğinden şablon dosyaları ayarlanır ve diğer kişiler için güncellenmez.

Bir şirket araç kutusu projesinde birden fazla python geliştiricisi olan kuruluşlardaki insanlar, projenin ve tüm farklı dosyaların doğru bir şekilde sürümlendirilmesini ve yönetilmesini nasıl sağlar? Yoksa projeye Eclipse (komut dosyaları tarafından kullanılan şablon katmanları ve GDB'ler dahil) girer ve insanların dosyaları doğru bir şekilde kontrol etmesini umarlar mı?


Şu anda SVN'de (şablonlar, katman dosyaları, kaynak kodu, araç kutuları) her şey var mı? Bazı insanların düzgün bir şekilde kontrol etmemesi sorunu mu?
Chad Cooper

Katman dosyaları ve şablon veri kümeleri hariç. Evet, ne zaman bittiklerini kontrol etmiyorlar ve ayrıca Eclipse'de (bildiğim kadarıyla) bir dosyanın en son sürümünü (örn. Tbx) almak için manuel olarak en son sürüme güncellemeniz gerekiyor. Sadece başkalarının bunu yapmanın daha akıllı bir yolu olup olmadığını merak ediyorum, o zaman şu anda
Rob

Yanıtlar:


5

Diğer geliştiricilerle çalışacağımı bilersem, bugünlerde yaptığım ilk şeylerden biri Jenkins gibi bir Continuos Entegrasyon sunucusu kurmak .

Buradaki fikir, her check-in sonrasında test paketinizi her zaman tetiklemektir ve başarısız olursa hemen otomatik bir e-posta alırsınız. Sizin durumunuzda, bu basit bir Selenyum betiği olabilir . Bu, bir tarayıcıyı veya ArcMap'i otomatikleştiren bazı ArcObjects komut dosyasını tıklar. Orada Selenyum hakkında birkaç sunum var .

Jenkins'le ilgili en güzel şey, diğer teknolojileri (yapı sistemleri, tiftik vb.) Entegre etmenizi / geliştirmenizi sağlayan birkaç eklenti olmasıdır . Kodunuzun ne kadarının test kapsamında olduğunu gösteren harika raporlar alabilirsiniz. Bunlar kurulum gerçekten çok kolay .

Şahsen, SVN yerine, Git ve GitHub ile entegre olmayı seviyorum ... bunu kimlik doğrulama için GitHub'a güvenmek gibi birçok avantajı var.

Ama elbette, ilk adım Jenkins'i çalıştırmaktır. Hiç yapmadıysanız, bir gün ayırın ve çok ilginç olabileceğinden çok nefes alın ... ama bir kez koştuğunuzda, gerçekten harika.


7

İyi anladım, sorunlarınızdan biri, geliştiricilerin SVN'yi düzgün kullanmamaları ve bu da SVN deposundaki içeriğin kararsız olmasına izin veriyor.

Yani belki birkaç şey deneyebilirsiniz:

Net bir havuz kullanım politikası belirleme

Tüm geliştiricilere havuzu kullanma yolunu, ne zaman ve ne taahhütte bulunacaklarını açıkça belirtin. Böylece havuz her zaman projenin çalışan bir kopyasına sahiptir.

Dağıtılmış bir kontrol sistemi kullanma

Git veya Mercurial gibi dağıtılmış bir kontrol sistemi kullanırsanız , her kullanıcı veri havuzuna bağlı kalabilir ve sürümlerini yalnızca çalışacağından emin olduklarında merkezi bir sisteme gönderebilir, hatta her kullanıcı için taahhüt pencereleri bile ayarlayabilirsiniz . birbirlerinin koduna basmayın.

Bunu söyleyerek, sizin durumunuzda Mercurial'a giderdim, çünkü Python'da geliştirildi ve ihtiyaçlarınıza göre uyarlamak için kancalar oluşturabilirsiniz. Ve SVN'den gelen öğrenme eğrisi oldukça kolay olduğu için ... başlangıç ​​için iyi bir nokta , aslında SVN yeniden eğitim adı verilen bir bölüme sahip olan hginit öğreticisidir.


2

Sorumlu birine ve daha fazla hesap verebilirliğe ihtiyacınız olduğunu düşünüyorum. Benim önerim araç kutuları için bir yönetici atamak veya işe almak olacaktır. Genel araç kutusunu ve alanındaki her şeyi yönetici dışında salt okunur yapın. Yönetici, SVN alanı dışındaki öğeler için işlerin test edildiğinden, teslim edildiğinden (veya yönetildiğinden) sorumlu olabilir. Yönetici insanların ne yaptığını görme şansı elde edeceğinden, birisinin ne zaman eğitime ihtiyacı olduğunu bilir, yani işleri yanlış yapan insanları yakalayabilir.


2

Bu bir teknoloji probleminden ziyade bir insan problemidir. Araç kutusu ve şablon dosyaları Kaynak Denetimi dışında düzenlenmektedir, bu nedenle üzerinde denetim yoktur. Bu dosyalar ikili dosyalar olmalarına rağmen sürüm denetiminde olmalıdır ve bunları ayırt edemez veya karşılaştıramazsınız. Genel bir Thumb kuralı olarak, kodunuzdan oluşturulmayan ve kodu çalıştırmak veya derlemek için gerekli olan her şey Kaynak Denetimi altında olmalıdır.

Bu şekilde, tüm proje kaynak kontrolü altında olacak ve her zaman çalışan bir kopya olacaktır. Geliştiriciler, kilitlendikten sonra araç kutusunu ve şablonu yerel sürümlerinde düzenlemeli ve yerel kopyaları çalışırken geri yüklemelidir.

Benzer

... check-in yapmadığından diğer kişiler için güncellenmedi

Bu bir insan sorunudur ve tüm geliştiricileriniz bunun neden önemli olduğunu anlamadıkça hiçbir teknoloji yardımcı olmayacaktır.


2

Araç kutusu, araç kutusunu düzenleyen birden fazla kişi tarafından rutin olarak dağıtılır

Bu özel sorun için, araç kutumuzu bir ArcSDE Veritabanına yerleştirdik. Başka tür bir veritabanı ile denemedim! İki kişi aynı aracı aynı anda düzenlemedikçe harika çalışır. Dosya araç kutusundan (.tbx) daha az sorun var.


Birden fazla kişinin farklı araçları aynı anda düzenleyebilmesi için araç kutusunu SDE'de sürümlendirdiğinizi mi söylüyorsunuz? Bu yaklaşımla ilgili bir sorununuz olmadı mı?
Cindy Jayakumar

Hayır, bir araç kutusu geliştirebileceğinizi sanmıyorum. SDE'de sadece bir araç kutusu oluşturursunuz. Ve birden fazla kişi aynı anda farklı araçları düzenleyebilir. Açıkçası birisi aynı aracı düzenlerse ve ArcToolbox olarak içeriği araç kutusunun açılışında (SDE) yüklerse ve başka biri araç kutusunun açılmasından bu yana düzenlenmiş bir aracı açarsa (SDE) iki sorun . Daha sonra bilindiği gibi küçültülebilir, ArcMap'i yeniden çağırabilir veya SDE bağlantısını kapatabilir ve yeniden açabilirsiniz. Umarım bu açıktır.
jeb
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.