Собственно вопрос ко всем.
1. Как часто вам приходится сравнивать орги (дата, метадата) ?
2. Что вы сравниваете ?
3. Почему(из-за чего) Вам нужно сравнивать орги ?
4. В каком виде Вам удобнее получать результат сравнения ?
Если есть дополнительные комментарии буду рад.
Присоединяюсь к Максиму.
Никогда не приходилось этим заниматься. Задача достаточно специфическая.
Я так понимаю это нужно в целях разработки - для того чтобы быть уверенным в том что два дев орга или дев орг и сандбокс идентичны?
А вообще я вижу это так:
проверка "переменных данных" в базе нет смысла сравнивать.
проверка "постоянных данных" (конфигурация, права доступа) имеет смысл сделать отдельную страницу самопроверки.
проверка кода и структуры базы данных - я думаю достаточно ant(Migration Tools) и какой-нибудь утилиты для сравнения двух папок (самое примитивное). Можно автоматизировать - написать скрипт, который будет тянуть все через Tooling API и сравнивать с эталоном.
Да мне собственно раньше это тоже было не нужно. Но учитывая что развели бардак. Нужно проверить что реально есть в UAT. Это что касается метадаты. Теперь переходим к дате. В проекте порядка 28 различных кастом сеттингов, которые немного меняются от орга к оргу. Тут тоже надо быть уверенным что в нужном орге нужные данные.
з.ы. А учитывая косяки салесфорса при переносе метаданы. Вопрос быстрого сравнения стоит очень остро.
Ну большую часть таких проблем я думаю решат "максимальные" тесты.
Если что-то где-то будет не хватать, то тесты покажут.
Другое дело что тесты писать геморно и не всегда есть время, а один раз написать скрипт, потом окажется выгоднее.
Про тесты вообще отдельная тема. Они в текущем релизе покрывают 32 процента кода :). Еще варианты ?
Залить в гит и сделать дифф?
И что я потом с этим дифом буду делать? Наши черти хотят репорт в котором будет видно что было, что стало. И проблема что я делаю этот отчет, а проверяет другой человек.
+1. Вообще по уму ветки Git'а должны быть синхронизированы с Org'ами, таким образом сведя вопрос к сравнению внутри Git'а.
Это если по уму. А если доступ к гиту есть только у 2-х человек из 10 это трудно выполнимо. Плюс к этому все пасуться на одном орге. И жирная точка - есть только один бранч в гите. И вот это все сделал наш волшебный архитектор-индус.
З.ы. маленькое лирическое отступление. Оказывается работники салесфорса на проекте за старт нового релиза получают бонусы. И как следствие из этого их не волнует завершение уже начатого релиза. Поэтому текущий релиз длится уже почти 5 месяцев вместо 2-х.
Дак прекрасно жеж.
Вполне себе стандарт работы с индусами!
Могу только посочувтсвовать. Вообще при трудоустройстве надо обращаться внимание на количество индусов в команде, а уж если он начальние/архитектор ...
Ну с этим вопросом к салесфорсу:)
В общем сделал я автоматическое сравнение. Сравнивает выбранную метедату и выводит отчет. Разница, то что есть только на первом орге, то что есть только на 2-м орге. Думаю пока хватит.
Слушайте а вроде как Force.com IDE перед деплоем умеет показывает разницу Org'ов. Эту фичу оттуда никак нельзя отодрать? Force.com IDE вроде как Open Source сейчас.
Может и можно, но это для больших оргов работает это ОЧЕНЬ МЕДЛЕННО.
Единственный выход - писать свою тулзу под API. Ну я думаю wilder тебе не привыкать 
Уже давно все написано и работает. Следующая задача на повеске, поиск строковых констант в коде. Для проверки ленивых девелоперов, которые не используют Custom Labels.
Regex я думаю справится.
Остается только правила придумать.
apex чуть проще я думаю будет - лови все что в ковычках, исключая какие-нибудь ложные срабатывания типо динамических соклов, динамических обращений к классам, проверки на ''.
С Visialforce я думаю будет больше геморра.
Так точно, только сложный регекс получается, ну да ладно, главное что бы салесфорс переварил.
У них многофункциональное назначение, в том числе и для этого. Просто за счет того что к Custom Labels можно легко добавить перевод их и используют.
Полностью поддерживаю wilder по поводу ленивых программистов и Custom Labels.
Сам с недавних пор (как начал работать с русским заказчиком) принял для себя это правило - все строковые константы ТОЛЬКО в Custom Labels. В коде ни одной строки (кроме динамического программирования, про что я писал выше). Да, много лишних телодвижений, но знаете как неприятно когда в коде появляются русские "Сохранить" "Назад" "Изменения успешно сохранены" когда ты работаешь под английским языком.
Для англоязычных проектов это конечно не особо актуально. Три года вполне успешно без них обходился.
Хотя директор на прошлой работе бил по пальцам когда проект сдавался без custom labels.
По-моему, требования про строковые литералы в коде применимо к любой технологии, это не Salesforce specific. Ну вот в .NET и Java есть файлы ресурсов, все примерно также.
Согласен. В Rails тоже можно использовать функционал i18n - все строковые константы выносятся в отдельный файл со структурой label:value и в коде ставил t('label'). Очень удобно. А еще клонируем такие файлы для каждого языка и получаем поддержку мультиязычности. Так что Mike V прав, это популярная практика.
Вот чего нашел по поводу Сравнения двух оргов
http://www.tquila.com/blog/2015/01/08/org-compare
Ну собственно я уже такое реализовал, потому что всегда не долюбливал решения которые вытягивают данные неизвестно куда и там уже даляют манипуляции с ними.
