Abbiamo un progetto di sviluppo in Python (ArcGIS 10). Questo progetto prevede una combinazione di toolbox, modelli di mappe, file di layer, modelli di geodatabase di file (che fungono da modelli importati in una mappa da script) e varie altre cose.

Usiamo Eclipse come nostro editor di sorgenti e SVN come nostro repository di codice sorgente.

Anche se abbiamo un problema a mantenere tutti i file (che non sono file PY) in un progetto sincronizzato da parte di tutti. La casella degli strumenti viene sistematicamente incasinata da più persone che modificano la casella degli strumenti, quindi i file dei modelli vengono adattati e quindi non aggiornati per altre persone in quanto non vengono ricontrollati.

In che modo le persone nelle organizzazioni con più di uno sviluppatore Python su un progetto di toolbox aziendale garantiscono che il progetto e tutti i diversi file vengano aggiornati e gestiti correttamente? O è un caso attraverso tutto ciò che va in Eclipse (inclusi i livelli dei template e GDB usati dagli script) nel progetto e speri che le persone controllino i file correttamente?

Se so che lavorerò con altri sviluppatori, una delle prime cose che faccio oggi è configurare un server di integrazione continua come Jenkins .

L'idea è di attivare sempre la tua suite di test dopo ogni check-in e riceverai subito un'e-mail automatica in caso di errore. Nel tuo caso, potrebbe essere una semplice sceneggiatura di selenio . Fa clic su un browser o su alcuni script ArcObjects che automatizzano ArcMap. Esistono diverse presentazioni sul selenio .

La cosa bella di Jenkins è che ci sono diversi plugin che ti permettono di integrare / sfruttare altre tecnologie (sistemi di costruzione, lanugine, ecc . ) . Puoi ottenere fantastici rapporti sulla quantità di codice coperta dal test. Sono davvero facili da configurare .

Personalmente, invece di SVN, mi piace integrarmi con Git e GitHub ... ci sono molti vantaggi nel fare questo come affidarsi a GitHub per l'autenticazione.

Ma ovviamente, il primo passo è far funzionare Jenkins. Se non l'hai mai fatto, prenota un giorno e respira molto poiché può essere molto eccentrico ... ma una volta che lo hai eseguito, è davvero fantastico.

Se ho capito bene, uno dei tuoi problemi è che gli sviluppatori non usano correttamente SVN e questo, rende instabile il contenuto nel repository SVN.

Quindi forse puoi provare un paio di cose:

Impostare un criterio di utilizzo chiaro del repository

Spiegare a tutti gli sviluppatori il modo di utilizzare il repository e quando e cosa impegnare. Quindi il repository ha sempre una copia funzionante del progetto.

Utilizzare un sistema di controllo distribuito

Se si utilizza un sistema di controllo distribuito come Git o Mercurial , ogni utente può impegnarsi nel proprio repository e inviare le proprie versioni a uno centralizzato solo quando sono sicuri che funzionerà, è possibile persino impostare finestre di commit per ciascun utente in modo che non calpestare l'altro codice.

Detto questo, nel tuo caso sceglierei Mercurial, perché è sviluppato in Python e puoi creare ganci per adattarlo alle tue esigenze. E poiché la curva di apprendimento di SVN è abbastanza semplice ... un buon punto di partenza è il tutorial hginit , che in realtà ha una sezione chiamata rieducazione SVN.

Penso che tu abbia bisogno di qualcuno responsabile e maggiore responsabilità. Il mio suggerimento sarebbe di nominare o assumere un amministratore per gli strumenti. Rendi la cassetta degli attrezzi pubblica e tutto quanto nel suo spazio di sola lettura tranne che per l'amministratore. L'amministratore può essere responsabile di assicurarsi che le cose vengano testate, archiviate (o gestite - nel caso di elementi al di fuori dello spazio SVN). Poiché l'amministratore avrà la possibilità di vedere cosa stanno facendo le persone, lui / lei saprà quando qualcuno ha bisogno di formazione, cioè può catturare le persone che fanno cose in modo improprio.

Questo è un problema di persone piuttosto che un problema di tecnologia. La casella degli strumenti e i file modello vengono modificati al di fuori del controllo del codice sorgente, quindi non esiste alcun controllo su di esso. Questi file dovrebbero avere il controllo della versione anche se sono file binari e non è possibile differenziarli o confrontarli. Come regola generale di Thumb, tutto ciò che non viene generato dal codice ed è necessario per eseguire o compilare il codice, dovrebbe essere sotto il controllo del codice sorgente.

In questo modo l'intero progetto sarà sotto il controllo del codice sorgente e ci sarà sempre una copia funzionante. Gli sviluppatori dovrebbero modificare la casella degli strumenti e il modello nella loro versione locale dopo il blocco e ricollegare quando la loro copia locale funziona.

Quanto a

... non aggiornato per altre persone in quanto non sono registrati nuovamente

Questo è un problema di persone e, a meno che tutti i vostri sviluppatori non capiscano perché questo è importante, nessuna tecnologia sarà di aiuto.

La casella degli strumenti viene sistematicamente incasinata da più persone che modificano la casella degli strumenti

Per questo particolare problema, inseriamo la nostra cassetta degli attrezzi in un database ArcSDE. Non ho provato con altri tipi di database! A meno che due persone non modifichino lo stesso strumento contemporaneamente, funziona alla grande. Davvero meno problemi rispetto a file toolbox (.tbx).