Как планировать релизы для проекта MS CRM 2016

Question

Мы получили несколько улучшений как часть проекта на MS CRM 2016 на предварительной реализации. Клиент хочет выпускать UAT и PRod после каждого спринта.

Плюс каждый спринт состоит из 3 недель, из которых 2 недели (кодирование + тестирование SIT) и 1 неделя UAT, , например. Sprint 1 начнется на первой неделе, а UAT будет в Неделе 3, но котировка Sprint 2 начнется на третьей неделе (когда бизнес тестирует спринт 1 в UAT)

Поэтому я столкнулся с проблемой планирования этих выпусков , нужно ли мне 2 среды DEV или как это сделать только в 1 среде DEV. Просьба помочь

Answer 1

Обычно мы планируем выпуск на основе сроков. И на основе этого мы планируем как требуемую среду CRM, так и очень важные ветви TFS.

Типичный рабочий процесс может проходить через следующие этапы: DEV -> TEST (UAT) -> Staging -> Production.

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

Поэтому вы обычно хотите сохранить их в двух разных средах и ветвях TFS.

Так, например, при разработке Sprint 1 вы можете быть в следующей ситуации:

Спринт 1

• DEV (где вы на самом деле разработки новых функций)
• TEST (где развернуть характеристики, которые готовы к тестированию)
• Проводка (ничего там еще нет)
• Производство (ничего еще нет)

Во время работы над Sprint 2 вы можете иметь:

• DEV (где разрабатывать новые функции Sprint 2)
• TEST (где вы проверить Sprint 2 функции будут готовы для тестирования)
• подмостей (который вы оставляете с Sprint 1 только для потенциальных исправлений ошибок)
• производства (все еще с Sprint 1 материал)

После Sprint 2 г elease все среды будут соответствовать, а затем начнутся снова.

Это был только один пример. В зависимости от количества команд разработчиков и выпусков может стать еще сложнее.