¿Trabajar en un equipo de proyecto de desarrollo de Python con ArcGIS?

Question

Tenemos un proyecto de desarrollo en Python (ArcGIS 10). Este proyecto implica una mezcla de cajas de herramientas, plantillas de mapas, archivos de capas, plantillas de geodatabases de archivos (que actúan como plantillas que se importan en un mapa por medio de scripts) y varias otras cosas.

Utilizamos Eclipse como editor de código fuente y SVN como repositorio de código fuente.

Aunque tenemos un problema con mantener todos los archivos (que no son archivos py) en un proyecto sincronizado por todos. La caja de herramientas rutinariamente se desordena por múltiples personas que editan la caja de herramientas y luego los archivos de plantillas se ajustan y luego no se actualizan para otras personas ya que no se comprueban de nuevo.

¿Cómo se asegura la gente en organizaciones con más de un desarrollador de python en un proyecto de caja de herramientas de la empresa que el proyecto y todos los diferentes archivos se versionan y gestionan correctamente? ¿O es un caso a través de todo va en Eclipse (incluyendo capas de plantillas y GDB utilizado por las secuencias de comandos) en el proyecto y la esperanza de que la gente comprobar los archivos correctamente?

Answer 1

Si he entendido bien, uno de sus problemas es que los desarrolladores no están utilizando correctamente el SVN y esto, deja que el contenido en el repositorio SVN sea inestable.

Así que puedes probar un par de cosas:

Establezca una política clara de uso de los repositorios

Dejar claro a todos los desarrolladores la forma de utilizar el repositorio y cuándo y qué confirmar. Así que el repositorio tener siempre una copia de trabajo del proyecto.

Utilizar un sistema de control distribuido

Si utiliza un sistema de control distribuido como Git o Mercurial , cada usuario puede hacer un commit en su repositorio y sólo envían sus versiones a uno centralizado cuando están seguros de que va a funcionar, tal vez incluso se puede establecer ventanas de compromiso para cada usuario para que no pisen el código de los demás.

Dicho esto, en tu caso me decantaría por Mercurial, porque está desarrollado en Python y puedes crear hooks para adaptarlo a tus necesidades. Y porque la curva de aprendizaje de SVN es bastante fácil... un buen punto para empezar es hginit tutorial, que en realidad tienen una sección llamada SVN reeducación.

Answer 2

Si sé que voy a trabajar con otros desarrolladores, una de las primeras cosas que hago hoy en día es configurar un Integración continua servidor como Jenkins .

La idea es activar siempre el conjunto de pruebas después de cada registro y recibirás un correo electrónico automático de inmediato si falla. En su caso, podría ser un simple Selenium script . Que hace clic en un navegador, o algún ArcObjects script que automatiza ArcMap. Hay varias presentaciones por ahí sobre el selenio .

Lo bueno de Jenkins es que hay varios plugins que permiten integrar/aprovechar otras tecnologías (sistemas de construcción, lint, etc.) . Puede obtener informes impresionantes sobre la parte de su código que está siendo cubierta por la prueba. Son muy fácil de configurar .

Personalmente, en lugar de SVN, me gusta integrar con Git y GitHub... hay varias ventajas de hacer esto como confiar en GitHub para la autenticación.

Pero, por supuesto, el primer paso es poner en marcha a Jenkins. Si nunca lo has hecho, resérvate un día y respira mucho ya que puede ser muy estrafalario... pero una vez que lo tienes funcionando, es realmente impresionante.

Answer 3

Se trata de un problema de personas más que de tecnología. La caja de herramientas y los archivos de plantilla se están editando fuera de Source Control, por lo que no hay control sobre ello. Estos archivos deberían estar en el control de versiones aunque sean archivos binarios y no se puedan diferenciar o comparar. Como regla general, cualquier cosa que no se genere a partir de su código, y que se requiera para ejecutar o compilar el código, debería estar bajo Control de Fuentes.

De este modo, todo el proyecto estará bajo el control de las fuentes, y siempre habrá una copia de trabajo. Los desarrolladores deben editar la caja de herramientas y la plantilla en su versión local después de bloquearla y volver a confirmarla cuando su copia local funcione.

En cuanto a

...no se actualiza para otras personas ya que no se registran de nuevo

Se trata de un problema de personas, y a menos que todos sus desarrolladores entiendan por qué es importante, ninguna cantidad de tecnología va a ayudar.

Answer 4

La caja de herramientas se estropea rutinariamente cuando varias personas editan la caja de herramientas

Para este problema en particular, ponemos nuestra caja de herramientas en una base de datos ArcSDE. No he probado con otro tipo de base de datos. A menos que dos personas editar la misma herramienta al mismo tiempo, funciona muy bien. Realmente menos problemas que con la caja de herramientas de archivos (.tbx).

Answer 5

Creo que se necesita un responsable y más responsabilidad. Mi sugerencia sería nombrar o contratar a un administrador para la(s) caja(s) de herramientas. Haz que la caja de herramientas pública y todo lo que hay en su espacio sea de sólo lectura, excepto para el administrador. El administrador puede ser responsable de asegurarse de que las cosas se prueban, se registran (o se gestionan - en el caso de los elementos fuera del espacio SVN). Dado que el administrador tendrá la oportunidad de ver lo que la gente está haciendo, él / ella sabrá cuando alguien