Nous avons un projet de développement en Python (ArcGIS 10). Ce projet implique un mélange de boîtes à outils, de modèles de carte, de fichiers de couches, de modèles de géodatabase fichier (agissant comme des modèles importés dans une carte par des scripts) et diverses autres choses.

Nous utilisons Eclipse comme éditeur source et SVN comme référentiel de code source.

Bien que nous ayons un problème à garder tous les fichiers (qui ne sont pas des fichiers py) dans un projet synchronisé par tout le monde. La boîte à outils est régulièrement gâchée par plusieurs personnes qui modifient la boîte à outils, puis les fichiers de modèle sont ajustés et ne sont pas mis à jour pour d'autres personnes car ils ne sont pas réarchivés.

Comment les personnes dans les organisations avec plus d'un développeur python sur un projet de boîte à outils d'entreprise s'assurent-elles que le projet et tous les différents fichiers sont correctement versionnés et gérés? Ou est-ce un cas à travers tout ce qui se passe dans Eclipse (y compris les couches de modèles et les GDB utilisés par les scripts) dans le projet et espère que les gens extraient correctement les fichiers?

Si je sais que je vais travailler avec d'autres développeurs, l'une des premières choses que je fais de nos jours est de configurer un serveur d' intégration continue comme Jenkins .

L'idée est de toujours déclencher votre suite de tests après chaque enregistrement et vous obtiendrez immédiatement un e-mail automatisé en cas d'échec. Dans votre cas, il pourrait s'agir d'un simple script Selenium . Cela clique autour d'un navigateur ou d'un script ArcObjects qui automatise ArcMap. Il existe plusieurs présentations sur le sélénium .

La chose intéressante à propos de Jenkins, c'est qu'il existe plusieurs plugins qui vous permettent d'intégrer / d'exploiter d'autres technologies (systèmes de construction, peluches, etc.) . Vous pouvez obtenir des rapports impressionnants sur la proportion de votre code couverte par le test. Ils sont vraiment faciles à installer .

Personnellement, au lieu de SVN, j'aime m'intégrer à Git et GitHub ... il y a plusieurs avantages à le faire comme s'appuyer sur GitHub pour l'authentification.

Mais bien sûr, la première étape consiste à faire fonctionner Jenkins. Si vous ne l'avez jamais fait, réservez un jour et respirez beaucoup car cela peut être très excentrique ... mais une fois que vous l'avez fait fonctionner, c'est vraiment génial.

Si j'ai bien compris, l'un de vos problèmes est que les développeurs n'utilisent pas correctement le SVN, ce qui laisse le contenu du référentiel SVN instable.

Alors peut-être que vous pouvez essayer deux ou trois choses:

Définir une politique claire d'utilisation du référentiel

Expliquez clairement à tous les développeurs comment utiliser le référentiel et quand et quoi engager. Ainsi, le référentiel a toujours une copie de travail du projet.

Utiliser un système de contrôle distribué

Si vous utilisez un système de contrôle distribué comme Git ou Mercurial , chaque utilisateur peut valider son référentiel et n'envoyer ses versions à un système centralisé que s'il est sûr que cela fonctionnera, vous pouvez peut-être même définir des fenêtres de validation pour chaque utilisateur afin qu'il ne 't pas sur l'autre code.

Cela dit, dans votre cas, je choisirais Mercurial, car il est développé en Python et vous pouvez créer des crochets pour l'adapter à vos besoins. Et parce que la courbe d'apprentissage de SVN est assez facile ... un bon point de départ est le tutoriel hginit , qui a en fait une section appelée rééducation SVN.

Je pense que vous avez besoin de quelqu'un en charge et de plus de responsabilité. Ma suggestion serait de nommer ou de recruter un administrateur pour la ou les boîtes à outils. Rendez la boîte à outils publique et tout ce qui se trouve dans son espace en lecture seule, sauf pour l'administrateur. L'administrateur peut être responsable de s'assurer que les choses sont testées, archivées (ou gérées - dans le cas d'éléments en dehors de l'espace SVN). Étant donné que l'administrateur aura la chance de voir ce que font les gens, il saura quand quelqu'un a besoin de formation, c'est-à-dire qu'il peut surprendre des gens qui ne font pas les choses correctement.

Il s'agit d'un problème humain plutôt que d'un problème technologique. La boîte à outils et les fichiers de modèle sont en cours d'édition en dehors du contrôle de code source, il n'y a donc aucun contrôle sur celui-ci. Ces fichiers doivent être sous contrôle de version même s'ils sont des fichiers binaires et que vous ne pouvez pas les différencier ou les comparer. En règle générale, tout ce qui n'est pas généré à partir de votre code et qui est requis pour exécuter ou compiler le code doit être sous contrôle de source.

De cette façon, l'ensemble du projet sera sous le contrôle de la source et il y aura toujours une copie de travail. Les développeurs doivent modifier la boîte à outils et le modèle dans leur version locale après le verrouillage et valider à nouveau lorsque leur copie locale fonctionne.

Quant à

... pas mis à jour pour les autres personnes car elles ne sont pas réenregistrées

C'est un problème de personnes, et à moins que tous vos développeurs ne comprennent pourquoi c'est important, aucune quantité de technologie ne pourra vous aider.

La boîte à outils est systématiquement gâchée par plusieurs personnes qui modifient la boîte à outils

Pour ce problème particulier, nous avons placé notre boîte à outils dans une base de données ArcSDE. Je n'ai pas essayé avec un autre type de base de données! À moins que deux personnes éditent le même outil en même temps, cela fonctionne très bien. Vraiment moins de problèmes qu'avec la boîte à outils de fichiers (.tbx).