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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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