D365FO 1707 PU12 - Как лучше всего делать резервное копирование D365 так, чтобы его быстро восстановить?

[MarinaAX]

Всем привет!

Подскажите, пожалуйста, какое лучше решение использовать для следующего сценария:

1. Single-box виртуалка с D365FO 1707 PU12, развернутая через LCS.
2. Основная проблема:
   1. Разработчики ломают модели в PackagesLocalDirectory и это потом невозможно починить, используя восстановление только PackagesLocalDirectory.
3. Стоят задачи:
   1. Обеспечить быстрое восстановление резервной копии D365FO single-box.
   2. Обеспечить быстрое резервное копирование. Срок хранения backup'ов - от 10 до 14 дней.
   3. Важно, чтобы можно было делать резервную копию по требованию.
   4. Резервная копия не включает базу данных SQL, т.к. база данных SQL находится в Azure SQL.
   5. Обеспечить насколько можно дешевое резервное копирование (если такое, конечно, возможно исходя из того, что быстрое и хорошее дешевым не бывает)

Если вас не затруднит, укажите, пожалуйста, инструкции, где видно как это настроить.

Смотрела Azure Recovery Services, Azure Backup Server, Snapshot - затрудняюсь сделать верный выбор и прошу помощи у Клуба Знатоков!

Заранее, большое спасибо за вашу помощь!

[Vadik]

Цитата:

Разработчики ломают модели в PackagesLocalDirectory

Помимо того чтобы поотрывать руки разработчикам, о каких бэкапах мы говорим, если на новых T1 машинах c 7.3 админского доступа уже нет? Разворачивайте VM локально на Hyper-V и бэкапьте-ресторьте что и куда угодно

[MarinaAX]

К сожалению, у нас все разработчики используют single-box среды D365, которые развёрнуты в Azure. Эти виртуалки доступны к управлению через портал Azure. Поэтому и возник вопрос.

[vmoskalenko]

Я считаю что ДЕВ машинки не надо бекапить совсем.

1. Проще Дев машинку удалить. Создать новую. Накатить свежий код из репозитория (TFS/VSTS)

2. Это ж как затратно держать для каждого девелопера машинку в Ажуре?... может дешевле выйдет купить каждому девелоперу по нормальному лэптопу.
Минимальная конфигурация 16G RAM, 300GB SSD
Моя конфигурация 32GB RAM, 1TB SSD

[pitersky]

Поддержу предыдущего оратора - дев-машины в ажуре держать глупо. Снять с lcs последнюю версию и развернуть её на ноуте - дело пары часов, сам этим занимался неоднократно.

[Vadik]

Цитата:

Сообщение от pitersky

Поддержу предыдущего оратора - дев-машины в ажуре держать глупо. Снять с lcs последнюю версию и развернуть её на ноуте - дело пары часов, сам этим занимался неоднократно.

Развернуть VM - легко, не спорю. А по машине на проект? А две? А пять? А отресторить на них копии продуктива для отладки? Дюже мощный лэптоп нужен однако

Марина, мы на своих проектах VM машины на собственной подписке не практикуем - либо add-on-ы оплачиваемые клиентом, либо на клиентских мощностях, так что с бэкапом ничего путного не подскажу, да и задачу если честно до конца не понимаю. Если это реальный проект, то почему на нем держат тех кто все регулярно ломает? Что произойдет (должно произойти) с локальным приложением и source control при восстановлении, они же "разъедутся" ? Или это игрушечная машина?

[MarinaAX]

Решение, которое я теперь практикую:

1. Девелопер получает ванильную VM в облаке.
2. Накатывается последний PU и шаблоны отчётов с включением SSRS.
3. На VM устанавливается native Windows Backup feature.
4. Backup-ится папка PackagesLocalDirectory.
5. Если надо восстановить - переименовывается "старая" PackagesLocalDirectory и востанавливается ванильная PackagesLocalDirectory, используя Windows Backup.
6. После восстановления VM в Visual Studio удаляется старый workspace и map-ится по-новой.
7. Девелоперы у нас нежные, поэтому я делаю восстановления самостоятельно - по заявкам трудящихся, а VSTS и workspace на востановления с backup'а пока не жаловались. Часто бывает и ISV добавляют проблем, особенно когда пытаются перейти с overlayer на extension. Бывает и безуспешно... Ведь Visual Studio не научился сам понимать, когда надо удалять папки, если их никто не догадался "удалить" в VSTS.
8. В итоге - все счастливы, поют и танцуют как в индийских фильмах

[ax_mct]

Цитата:

Сообщение от pitersky

Поддержу предыдущего оратора - дев-машины в ажуре держать глупо. Снять с lcs последнюю версию и развернуть её на ноуте - дело пары часов, сам этим занимался неоднократно.

Я три года таскаю гробину с 32RAM и проклинаю все на свете. Одно зарядное устройство весит как мой мак.

Ажур не ажур, но на мой взгляд ноут лучше только как терминал. Серверная часть может даже дома быть в виде отдельного системного блока или отдельного минисервера. Практичнее разделить даже для домашних условий.

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

[ax_mct]

Цитата:

Сообщение от vmoskalenko

Я считаю что ДЕВ машинки не надо бекапить совсем.

1. Проще Дев машинку удалить. Создать новую. Накатить свежий код из репозитория (TFS/VSTS)

2. Это ж как затратно держать для каждого девелопера машинку в Ажуре?... может дешевле выйдет купить каждому девелоперу по нормальному лэптопу.
Минимальная конфигурация 16G RAM, 300GB SSD
Моя конфигурация 32GB RAM, 1TB SSD

Возможно для партнера уместнее своя серверная за счет в два раза более дешевых лаптопов.
Это $1500 c каждого девелопера которые идут на серверную.

Это только сначала радуешься мощи, а потом заколебывает

[MarinaAX]

Мои предложения развернуть скаченные из LCS'а VM-ки на местных Hyper-V хостах и отбить затраты за счёт экономии на облаке за 3-4 месяца натолкнулись на лёд непонимания - "Зачем так делать, если всё в облаке?!". Мой ответ: а зачем доказывать людям очевидные вещи! Поэтому по-преженему живём c "облачными" VM для девелоперов. Ну а что, для меня - job security

[Alex_KD]

Цитата:

Сообщение от MarinaAX

Решение, которое я теперь практикую:

1. Девелопер получает ванильную VM в облаке.
2. Накатывается последний PU и шаблоны отчётов с включением SSRS.
3. На VM устанавливается native Windows Backup feature.
4. Backup-ится папка PackagesLocalDirectory.
5. Если надо восстановить - переименовывается "старая" PackagesLocalDirectory и востанавливается ванильная PackagesLocalDirectory, используя Windows Backup.
6. После восстановления VM в Visual Studio удаляется старый workspace и map-ится по-новой.
7. Девелоперы у нас нежные, поэтому я делаю восстановления самостоятельно - по заявкам трудящихся, а VSTS и workspace на востановления с backup'а пока не жаловались. Часто бывает и ISV добавляют проблем, особенно когда пытаются перейти с overlayer на extension. Бывает и безуспешно... Ведь Visual Studio не научился сам понимать, когда надо удалять папки, если их никто не догадался "удалить" в VSTS.
8. В итоге - все счастливы, поют и танцуют как в индийских фильмах

А пробовали смотреть в сторону build server?
Там как раз такая же задача решается - откатит PackagesLocalDirectory на ванильный, накатить сверху файлы из VSTS и запустить build.
Смотрите шаг "Prepare for build", все упирается в robocopy.

Как бонус, установите VSTS agent, поменяйте powershell скриптик, настройте release pipeline. Если надо обновить - нажали кнопку, оно само все сделает. Дать права на кнопку разработчкима, уехать в отпуск.

[MarinaAX]

Цитата:

Сообщение от Alex_KD

Как бонус, установите VSTS agent, поменяйте powershell скриптик, настройте release pipeline. Если надо обновить - нажали кнопку, оно само все сделает. Дать права на кнопку разработчкима, уехать в отпуск.

Большое спасибо за совет! А могли бы Вы подробнее рассказать, про VSTS агент, PowerShell и настройку Release Pipeline, пожалуйста?

Заранее, большое спасибо!

[vmoskalenko]

Вот тут есть презентация http://smart-talks.org/event/smart-talks-143/
Но имейте ввиду, что на текущий момент нет доступа/нет API к LCS чтобы автоматизированно аплоадить тудой пакеты в библиотеку и управлять установкой на сервера. Поэтому, к сожалению, все что дальше BUILD Server - это уход от стандартных практик Майкрософт в области Dynamics.

[vmoskalenko]

Вот еще нашел скриптов про управление релизами в VSTS/Azure DevOps
https://github.com/laneswenka/d365-foee-alm

..хотя ходят слухи что скор-скоро будет все готово из коробки от Макрософта.