Как несколько разработчиков могут эффективно работать над одним приложением force.com?

Question

Компания, в которой я работаю, создает управляемое приложение force.com как интеграцию с предоставляемым нами сервисом.

У нас проблемы с одновременной работой над одним и тем же набором файлов из-за некачественного инструментария, поставляемого с плагином force.com Eclipse. Если 2 разработчика работают над одним файлом, одному из них выдается сообщение, которое он не может сохранить - после слияния он вынужден вручную заставить плагин отправить свои изменения на сервер вместе с нажатием 2 «Вы действительно уверены? сообщения.

По сути, инструментальное средство выполняет скудную работу по объединению изменений и заставляет минуты работы каждый раз, когда разработчик хочет сохранить, если другой человек изменил файл, над которым работает.

В настоящее время мы работаем над этим, в основном «блокируя» отдельные файлы, сообщая коллегам, кто редактирует файл.

Такое ощущение, что в наше время должен быть лучший путь. Кто-нибудь знает другой набор инструментов, который мы могли бы использовать, процесс, который мы могли бы изменить, или что-нибудь, что мы можем сделать, чтобы сделать это проще?

Answer 1

При работе с платформой Force.com моя текущая организация обнаружила, что в зависимости от ситуации может работать несколько разных подходов. Мы все без проблем используем плагин Eclipse Force.com и обнаружили, что следующие настройки работают хорошо.

У нас есть централизованная система управления версиями, которую мы разворачиваем от использования серии команд ant до экземпляра org разработчика. Затем мы, в зависимости от объема работы, либо разделяем ее на куски, где каждый разработчик имеет свою собственную организацию разработки и объединяет изменения и регулярно их тестирует, либо работает в одной организации разработки (чего, если у вас есть 2 разработчика, не должно быть). основная проблема) позволяет вам практически мгновенно интегрироваться.

Если вы оба пытаетесь работать с одним и тем же файлом, вы все равно должны заниматься парным программированием, но если вы работаете вместе над двумя компонентами одинаковой системы, совместное использование одной организации может позволить вам развиваться быстро и гибко, создавая скелет системы, которую вы хотите использовать, а затем индивидуально обрисовать детали.

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

Answer 2

У нас была / есть та же самая проблема, у нас есть команда из 10 разработчиков, работающая над приложением force.com, которое загружает классы вершин (> 300) и страницы VF (> 300).

Мы начали использовать плагин Eclipse, но нашли его:

1. слишком медленная работа за пределами США каждый раз, когда вызывается сохранение, занимает> 5 секций
2. ко многим проблемам слияния с командой из 10 разработчиков

Затем мы попытались разработать собственные песочницы, а затем объединить код. Это нормально для небольшого проекта, но когда у вас много файлов, и вам нужно перенести изменения между песочницами, управление становится невозможным, поскольку единственное, что хуже, чем инструмент разработки force.com, это инструменты развертывания / сборки force.com. Нет автоматизации, все вручную. Также нет простого способа перемещения данных между песочницами.

Наш третий подход состоял в том, чтобы просто отредактировать все наши страницы VF и код Apex в браузере. (не используя встроенный редактор, который отображается в нижней половине страницы, потому что он глючный и медленный), а просто с помощью обычного редактора в разделе setup >velop> Apex. Это работало хорошо. В дополнение к этому у нас также была запланированная работа, которая будет загружать весь наш код и сохранять его в нашем хранилище SVN. Мы также создали инструмент, позволяющий нам щелкать папку на рабочем столе, архивировать ее содержимое и развертывать ее как статические ресурсы для нас.

Однако этот подход все еще имеет свои недостатки, т. Е. Он медленно и болезненно развивается в облаке, их (Salesforce) идея развития как услуги сводит с ума. Кроме того, у нас нет реального SCM, у нас есть только его резервные копии.

Суть в том, что force.com - это CRM, а не платформа разработки, если можно? Беги, беги, уходи от него так быстро, как только сможешь. Использование его для чего-либо, кроме CRM, доставляет больше хлопот, чем оно того стоит. Даже их лозунг "Нет программного обеспечения" заставляет меня смеяться каждый раз

Answer 3

Каждый разработчик может работать в отдельной изолированной программной среде разработки (если у вас есть корпоративная версия, я думаю, 10 песочниц с полной конфигурацией и ограниченным количеством данных включены в плату?) Время от времени вы объединяете свои изменения (достаточно инструмента сравнения с любой системой контроля версий) и тестируете их в среде интеграции. Развитие цепочки-> интеграция-> тестирование системы-> вопросы и ответы-> производство могут быть полезны и по другим причинам.

Можно использовать отдельный трюк, если, например, 2 парня работают с одним и тем же триггером. Я изучил это на курсе "DEV 401" для разработчиков.

1. Переместите всю свою логику в классы. Шутки в сторону. Они также будут проще для модульного тестирования.
2. Добавить настраиваемое поле (множественный выбор списка) к объекту пользователя. Значения должны быть равны каждой отдельной функции, над которой работают люди. Он может содержать до 500 значений, поэтому вы должны быть в безопасности.
3. Для учетной записи разработчика 1 установите «feature1» в списке выбора. Установите "feature2" для другого парня.
4. В триггере напишите if, который проверяет наличие каждого значения списка выбора и вводит или оставляет вызов соответствующему классу. Это тратит впустую 1 запрос, но вы уверены, что будет вызван только тот код, который вы хотите.
5. Каждый разработчик продолжает работать в своем собственном файле класса.
6. Для проверки интеграции обеих функций просто установите множественный выбор на обе функции.

Я нашел этот трюк особенно полезным, когда код другого парня оказался неоптимальным и потреблял слишком много ресурсов. Я только что отключил его функцию в своей учетной записи и продолжил работать.

Этот прием можно в некоторой степени применить и к страницам Visualforce (если вы можете разделить их на компоненты).

Если вы не хотите тратить впустую запрос - используйте логику, например "имя пользователя содержит X";)

Answer 4

Ознакомьтесь с «Руководством по жизненному циклу разработки: разработка предприятия на платформе Force.com». Вы можете найти его на странице документации developer.force.com .

Answer 5

Я не знаком с force.com, но вы не можете использовать контроль исходного кода и перенести все файлы с force.com в свой репозиторий. Тогда вы можете выполнять свою работу и объединять изменения обратно в основную линию. Тогда всякий раз, когда это необходимо, подтолкнуть магистраль до force.com?

Answer 6

Возможно, вы захотите рассмотреть возможность работы с отдельными статическими ресурсами и страницами, а затем просто быть осторожными при редактировании объектов, классов и т. Д. Если большая часть вашей разработки происходит на стороне клиента (страница, статический ресурс, компонент / приложение молнии), вы можете быть заинтересованным в этом проекте: https://github.com/bvellacott/salesforce-build. В любом случае я настоятельно рекомендую использовать контроль версий. Если не на сервере, то хотя бы локально на вашем компьютере, если ваши коллеги перезаписывают вашу работу.