Всем привет! И до моей маленькой конторки дошло что надо использовать систему контроля версий. Вот только как это применить к sf я не знаю.
Я знаю что многие это юзают.
Вопрос:
Какими инструментами вы пользуетесь? Какие преимущества?
Где можно подробно почитать как все подружить с SF?
У меня все тривиально - в папке с проектом, созданным в Eclipse, лежит .Git. Две ветки - мастер и дэв. Мастер для прода, дев - песочница. Ну и мои ветки для отдельных задач. После выполнения задачи, моя ветка сливается в дэв. Мой начальник заливает код из дэв на прод и птм сам сводит дэв в мастер. Перед сведением в мастер, мастер обновляется до текущего состояния прода. Прод используется для нескольких проектов.
СФ у меня используется во многом как БД :-)
Chiz ты слишком сложно все объяснил. Только дев с опытом работы с системами контроля версий поймет про что ты пишешь.
DevNull
Вот тут есть информация про то как работать с git (и не только с git а вообще как правильно организовать работу с проектами)
https://developer.atlassian.com/sfdc/the-salesforce-development-workflow
https://www.youtube.com/watch?v=_eJn2qNDLHQ
Надеюсь до этого вы дошли не после того как нечаянно удалили(потеряли) исходники?
Ну, человек указал, что знает Java, PHP, C# и сейчас вот SF. Я даже когда свой первый проект делал сам, мне повесили CVS и сказали коммитить перед уходом.
О! Я еще пользуюсь GitExtensions для визуализации веток и различий.
На счет визуализации - я использую SourceTree, но он немного прожерливый - подлагивает часто.
Раньше пользовался TortoiseGit.
Ещё могу рекомендовать http://www.syntevo.com/smartgit/ - в разы шустрее SourceTree.
Нет, у нас все бекапится периодически)
Просто надо взять себя в руки и начать делать как надо, а не как хочется)
Знаю. Но не поверишь, мне такого не говорили) Я сайт один делал, там svn подключен был. Только коммитил и все. А дальше там сами разбирались. А вот тут решил разобраться сам.
Всем спасибо за инфу!!
Я пока уже запутался)
Надо разобраться как работать в FORCE.com IDE и не тыкать команду в консоли каждый раз как хочу сохранить код.
Это ты про что вообще?
При чем здесь FORCE.com IDE и команда в консоли на каждый раз?
Дима, расскажи подробно как у тебя происходит процесс разработки на SF с применением Git
Очень просто.
Если простой вариант - я так понимаю надо начать с него
Работаю с проектом в ММ как обычно. Делаю таску, отлаживаю, показываю заказчику. А когда задача закончена иду в Git client и делаю коммит с описание изменений.
Просто к папке MM проекта создан репозиторий git.
Тебе не надо каждый раз в Git бегать.
- 1 раз создал в папке с проектом git init и подключил к внешнему репозиторий (по желанию) если он есть.
- делаешь первый commit (initial commit) чтобы сохранить текущее состояние проекта.
ВСЕ!
Дальше работаешь пока в не код не созреет для того чтобы сделать коммит в репозиторий - абсолютно тоже самое что вы делали бекапы вручную.
С внешним хранилищем и несколькими разработчиками и разными оргами все немного сложнее :)
[img]http://googledrive.com/host/0B0eDASnW3Dtja1VRb2U4VHRMYW8[/img]
вот так у меня выглядит папка с проектом, созданным в Eclipse.
Как вы картинки вставляете?
Картинка
Так и вставляем, только на конце ссылки должно быть валидное имя картинки (.jpg, .png и так далее)
Сорри, влом было переделывать - это поведение из коробки bbcode парсера
Я вот сейчас пытаюсь настроить работу на проекте с двумя разработчиками и удалённым репозиторием на GitLab. Пока выходит, что репозиторий содержит ветку master для прода, и ветку "fullsand" условно говоря для песочницы, в которой работают 2 человека. У каждого разработчика локально есть MM проект для прода,и проект для песка, каждый их которых отслеживается гитом. Через sourcetree я к обоим подключаю удалёнку, и пушу локальный master песка в ветку sandbox удалённого. Из прода пушу maste в master соответственно. Из гитлаба ничего никуда автоматом не уходит просто служит хранилищем версий.
у нас in house, то есть мы развиваем только внутри компании орг и на фирме 8 девелоперов успешно работают по такой схеме:
все девелоперы работают в 1 фулл сэндбоксе (всего их 3), если сделал таск качаешь через ant все изменения которые относятся к таску и пушишь в git в dev бранч
гит связан с jenkins и git выполняет ant deploy на UAT сендбокс. Если деплой упадет получаешь ошибку почему, например сделал с новым полем а поле забыл закоммитить. Если билд сбилдился то всё таск выполнен (ну потом еще QA проверит конечно).
Каждую ночь идет валидация (деплой без деплоя) на прод.
когда происходит деплой то бранч просто отрезается после code freeze и мержится выше в staging и уходит на третий фул сендбокс. Там происходит еще 1 раунд тестов и staging промоутится до master и пушится в прод.
короче работает отлично. Сделал таск в сэндбоксе, запушил в git, если всё сделал правильно (и нет непереносимых антом изменений) то работа выполнена.
по такой схеме у нас сэндбоксы рефрешатся только тогда когда мы хотим свежую дату (не метадату) из прода
Как обстоят дела с destructivechanges?
Как обстоят дела с destructivechanges?
destructivechanges тоже происходят при деплое.
Как обстоят дела с destructivechanges?
destructivechanges тоже происходят при деплое.
Информация для destructive собирается ручками или автоматически ?
Как обстоят дела с destructivechanges?
destructivechanges тоже происходят при деплое.
Информация для destructive собирается ручками или автоматически ?
спросил как там происходит у деливери менеджера 
всё автоматически
destructivechanges идут отдельным деплоем, от меня надо опять же заделиверить изменения в гит (удаление файла)
файл удаляется, в случае чего его можно всегда вернуть выйдя на нужную версию бранча.
То есть ты хочешь сказать, что ты например поменял Api name поля и у вас старое поле удалиться автоматически. Или ты удалил какие-то значения из пиклиста и они тоже сами удаляться?
нет, поля надо удалять вручную их ант не удаляет, я говорил про апекс класс, его удалить можно
апдейт пиклиста это же просто апдейт метадаты, рекорды старые значения сохранят, как если бы ты вручную сапдейтил.
сделать можно только то что можно задеплоить антом. фишка в том что всё что нельзя (удаление полей, емейл темплейты и т.д.) я говорю сделать админу 
нет, конечно в процессе есть косяки. Если например мы меняем пиклист на лукап, API name совпадает и поле нельзя сменить тип со старого на новый то надо лезть вручную и вручную удалять старое поле перед деливери, иначе билд упадет с ошибкой что такой апдейт не допустим.
Я думал что у вас что-то новенькое есть:) а так я в курсе всех этих проблем.
