У нас є проект розвитку в Python (ArcGIS 10). Цей проект включає суміш інструментальних скриньок, шаблонів карт, файлів шарів, шаблонів баз даних файлів (виконуючи роль шаблонів, які імпортуються на карту за допомогою скриптів) та різних інших речей.

Ми використовуємо Eclipse як наш вихідний редактор, а SVN - як наш сховище вихідного коду.

Хоча у нас є проблема із збереженням усіх файлів (які не є py-файлами) у синхронізованому проекті всіма. Панель інструментів регулярно псується декількома людьми, що редагують панель інструментів, а потім файли шаблонів коригуються, а потім не оновлюються для інших людей, оскільки вони не перевіряються.

Як люди в організаціях, що мають більше одного розробника python у проекті інструментарію компанії, гарантують, що проект та всі різні файли будуть правильно розроблені та керовані? Або це випадок, коли все переходить у проект Eclipse (включаючи шаблони шаблонів та використовувані сценарії GDB), і сподіваємось, що люди перевірять файли правильно?

Якщо я знаю, що збираюся співпрацювати з іншими розробниками, однією з перших речей, які я зараз роблю, є налаштування сервера інтеграції неперервної дії, як Дженкінс .

Ідея полягає у тому, щоб завжди запускати тестовий набір після кожного заїзду, і ви отримаєте автоматичну електронну пошту відразу, якщо вона не працює. У вашому випадку це може бути простий скрипт Selenium . Це натискає браузер або якийсь скрипт ArcObjects, який автоматизує ArcMap. Існує кілька презентацій про Селен .

Класна річ про Дженкінса - це те, що є кілька плагінів, які дозволяють інтегрувати / використовувати інші технології (побудувати системи, вкладати тощо) . Ви можете отримати дивовижні звіти про те, яка частина вашого коду охоплюється тестом. Їх дуже просто встановити .

Особисто замість SVN я люблю інтегруватися з Git та GitHub ... Є кілька переваг цього зробити, як покладатися на GitHub для аутентифікації.

Але звичайно, перший крок - запустити Дженкінса. Якщо ви ніколи цього не робили, резервуйте один день і багато дихайте, оскільки це може бути дуже вигадливим ... але, як тільки ви його запустите, це справді приголомшливо.

Якщо я добре зрозумів, одна з ваших проблем полягає в тому, що розробники неправильно використовують SVN, і це дозволяє вмісту в сховищі SVN нестабільним.

Тож, можливо, ви можете спробувати пару речей:

Встановіть чітку політику використання сховища

Уявіть усім розробникам про те, як використовувати сховище та коли та що робити. Тож у сховищі завжди є робоча копія проекту.

Використовуйте розподілену систему управління

Якщо ви використовуєте розподілену систему управління, як-от Git або Mercurial , кожен користувач може взяти на себе зобов’язання зі своїм сховищем і лише надіслати свої версії до централізованої, коли він впевнений, що це буде працювати, ви можете навіть встановити вікна передачі даних для кожного користувача, щоб вони не працювали не наступайте на код один одного.

Говорячи про це, у вашому випадку я б пішов на Mercurial, тому що він розроблений в Python, і ви можете створити гачки, щоб підлаштувати його під ваші потреби. А тому, що крива навчання від SVN, це досить просто ... хорошим моментом для початку є підручник з hginit , який насправді має розділ під назвою перевиховання SVN.

Я думаю, що вам потрібен хтось відповідальний і більше відповідальності. Моєю пропозицією було б призначити або набрати адміністратора для панелі інструментів. Зробіть загальнодоступний інструментарій та все, що знаходиться в його просторі, лише для читання, крім адміністратора. Адміністратор може нести відповідальність за те, щоб перевірити, перевірити, перевірити (або керувати ними - у випадку з предметами поза SVN-простором). Оскільки адміністратор отримає можливість побачити, що люди роблять, він / вона дізнається, коли комусь потрібна підготовка, тобто він може спіймати людей, які роблять щось неправильно.

Це проблема людей, а не проблема технології. Панель інструментів та файли шаблонів редагуються поза Source Control, тому над цим контролю немає. Ці файли повинні знаходитись у контролі версій, навіть якщо вони є двійковими файлами, і ви не можете їх відрізняти чи порівнювати. За загальним правилом Thumb, все, що не генерується з вашого коду та вимагається для запуску чи компіляції коду, має знаходитись під контролем джерела.

Таким чином весь проект буде під контролем джерела, і завжди буде робоча копія. Розробники повинні відредагувати панель інструментів та шаблон у своїй локальній версії після блокування та повернутись назад, коли працює їх локальна копія.

Щодо

... не оновлюється для інших людей, оскільки вони не перевірені

Це проблема людей, і якщо всі ваші розробники не зрозуміють, чому це важливо, жодна кількість технологій не допоможе.

Панель інструментів звичайно псується декількома людьми, що редагують панель інструментів

Для цієї конкретної проблеми ми помістили наш інструментарій у базу даних ArcSDE. Я не намагався з іншим типом баз даних! Якщо дві людини не редагують один і той же інструмент одночасно, він чудово працює. Дійсно менше проблем, ніж із файловою панеллю інструментів (.tbx).