Как несколько разработчиков могут эффективно работать над одним приложением force.com?
Компания, на которую я работаю, создает управляемое приложение force.com как интеграцию с услугой, которую мы предоставляем.
У нас есть проблемы, работающие одновременно над тем же набором файлов из-за дрянных инструментов, которым предоставляют плагин Eclipse force.com. Если 2 разработчика работают над тем же файлом, каждому дают сообщение, что он не может сохранить - после того как он объединяется, он должен вручную вынудить плагин продвинуть его изменения в сервере наряду с нажатием на 2, 'Вы действительно верные' сообщения.
В основном инструменты делают дрянное задание слияния в изменениях и вызывают минуты работы каждый раз, когда разработчик хочет сохранить, если другой человек изменил файл, он продолжает работать.
Мы в настоящее время работаем вокруг этого, в основном 'блокируя' отдельные файлы путем уведомления коллег, кто редактирует файл.
Такое чувство, что должен быть лучший путь в этот день и возраст. Кто-либо знает о другом наборе инструментов, который мы могли использовать, обработать, мы могли измениться, или что-нибудь, что мы можем сделать для создания этого легче?
4 ответа
Я не знаком с force.com, но не могли бы вы использовать систему контроля версий и перетащить все файлы с force.com в свой репозиторий. Тогда вы все сможете выполнять свою работу и снова объединить свои изменения в основную ветку. Затем, когда это необходимо, подталкивайте основную ветку к force.com?
Взгляните на «Руководство по жизненному циклу разработки: развитие предприятия на платформе Force.com». Вы можете найти его на странице документации developer.force.com .
У нас была / есть такая же проблема, у нас есть команда из 10 разработчиков, работающих над приложением force.com, которое имеет множество классов вершин (> 300) и страниц VF (> 300) .
Мы начали использовать плагин Eclipse, но обнаружили его:
- слишком медленная работа за пределами США каждый раз, когда вызывается сохранение, занимает> 5 разделов
- для многих проблем слияния с командой из 10 разработчиков
Затем мы пробовал разрабатывать в наших собственных индивидуальных песочницах, а затем объединять код. Это нормально для небольшого проекта, но когда у вас много файлов и вам нужно передавать изменения между песочницами, становится невозможно управлять, поскольку единственное, что хуже инструментов разработки force.com, - это инструменты развертывания / сборки force.coms. Нет автоматизации, все вручную. Также нет простого способа перемещать данные между песочницами.
Наш третий подход заключался в том, чтобы просто отредактировать все наши страницы VF и код Apex в браузере. (не используя их встроенный редактор, который отображается в нижней половине страницы, потому что он содержит ошибки и работает медленно), а просто используя обычный редактор в разделе настройки> разработка> классы Apex. Это сработало нормально. В дополнение к этому у нас также было запланированное задание, которое должно было загрузить весь наш код и сохранить его в нашем репозитории SVN. Мы также создали инструмент, который позволяет нам щелкнуть папку на нашем рабочем столе, заархивировать ее содержимое и развернуть для нас как статические ресурсы.
Однако у этого подхода все еще есть свои недостатки, т.е.е. Разрабатывать в облаке медленно и болезненно, их (продавцов) идея «Разработка как услуга» безумна. Кроме того, у нас нет настоящего SCM, он действует только в качестве резервных копий.
Суть в том, что force.com - это CRM, а не платформа для разработки, если можно? беги, беги, уходи от этого так быстро, как только сможешь. Использование его для чего-либо, кроме CRM, - больше проблем, чем оно того стоит. Даже их слоган «Никакого программного обеспечения» всегда заставляет меня смеяться
Каждый разработчик может работать в отдельной изолированной программной среде разработки (если у вас корпоративная версия, я думаю, 10 песочниц с полной конфигурацией и ограниченным объемом данных включены в плату?) . Время от времени вы должны объединять свои изменения (достаточно инструмента сравнения из любой системы управления версиями) и тестировать их в среде интеграции. Цепочка разработка-> интеграция-> тестирование системы-> вопросы и ответы-> производство может быть полезна и по другим причинам.
Можно использовать отдельный трюк, если, например, два человека работают над одним и тем же триггером. Я изучил это на курсе "DEV 401" для разработчиков.
- Перенесите всю свою логику в классы. Шутки в сторону. Их тоже будет проще юнит-тестировать.
- Добавить настраиваемое поле (раскрывающийся список с множественным выбором) к объекту «Пользователь». Ценности должны быть равны каждой отдельной функции, над которой работают люди. Он может содержать до 500 значений, поэтому вы должны быть в безопасности.
- Для учетной записи пользователя разработчика 1 установите "feature1" в раскрывающемся списке. Установите "feature2" для другого парня.
- В триггере напишите
if, который проверяет наличие каждого значения раскрывающегося списка и вводит или прекращает вызов соответствующего класса.Это тратит 1 запрос, но вы уверены, что будет вызван только тот код, который вам нужен. - Каждый разработчик продолжает работать в своем собственном файле класса.
- Для проверки интеграции обеих функций просто установите множественный выбор, чтобы включить обе функции.
Я нашел этот трюк особенно полезным, когда чужой код оказался неоптимальным и потреблял слишком много ресурсов. Я только что отключил его функцию в своей учетной записи и продолжал работать.
Этот трюк можно в некоторой степени применить и к страницам Visualforce (если вы можете разделить их на компоненты).
Если не хотите терять запросы - используйте логику типа «имя пользователя содержит X»;)