|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
Товарищи, Может быть вопрос не совсем сюда, но тем не менее, подскажите пожалуйста как лучше постороить тестовую инфраструктуру. Пока мне видеться так: DEV среда - для разработчиков. Test среда - для тестировщиков. UAT - для тестирования бизнесом. Prod - он же prod. Какие слабые места в данной инфраструктуре? Или что я упускаю из виду. Спасибо :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2014, 14:57 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
Слабые места будут если прод нескольких версий. Ну т.е., несколько клиентов с разными версиями продукта, соответственно потенциально возможно что будет необходимость иметь кол-во ДЕВ, ТЕСТ кратно ПРОД стендам. А так всё норм. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 10:11 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
BadMFСлабые места будут если прод нескольких версий. Ну т.е., несколько клиентов с разными версиями продукта, соответственно потенциально возможно что будет необходимость иметь кол-во ДЕВ, ТЕСТ кратно ПРОД стендам. А так всё норм. Да даже если ПРОд будет один, такая инфраструктура не дает возможности поддержки нескольких релизов/проектов, например... т.е. пока текущий релиз/проект не окажется на проде (и не будет стабилизирован), начинать новые доработки скорее всего будет нельзя... Теоретически стабилизацию можно проводить на среде UAT, но это, ИМХО, плохая практика... Не знаю насколько масштабные у вас системы, если масштабные и рассчитаны на большое количество внутренних пользователей (например, банковский CRM), то на какой среде у вас предполагается обучение персонала новым фичам? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 11:03 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
BadMF, Версия клиента у всех одна. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 11:36 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
DexterI, Предполагаю что все доработки и стабилизации будут на этапе dev и test среды, т.е. после апрува ответственных лиц, продукт будет выкатываться в uat... Система достаточно масштабны ритейл...Обучение новым фичам в uat среде, т.е. к дев и тесту бизнеса вообще не будет, в uat предпологается что ит практически не будет... На счет новых релизов согласен, есть затык, его я не совсем учел...:( Как тогда быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 11:41 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
vot_takoyDexterI, Предполагаю что все доработки и стабилизации будут на этапе dev и test среды, т.е. после апрува ответственных лиц, продукт будет выкатываться в uat... Система достаточно масштабны ритейл...Обучение новым фичам в uat среде, т.е. к дев и тесту бизнеса вообще не будет, в uat предпологается что ит практически не будет... На счет новых релизов согласен, есть затык, его я не совсем учел...:( Как тогда быть? Зависит от релизной политики... ДЕВы и ТЕСТы надо умножать на количество релизов находящихся в производстве.. Например, имеет 2 релиза в производстве: Момент времени T1: 1. Среда ДЕВ1: заканчиваем разработку релиза 1 2. Среда ТЕСТ1: начинаем тестирование релиза 1 3. Среда ДЕВ2: начинаем разработку Релиза 2 Момент времени T2: 1. Среда ДЕВ1: начинаем разработку релиза 3 2. Среда ТЕСТ1: Заканчиваем тестирование релиза 1 3. Среда UAT: начинаем UAT релиза 1 4. Среда ДЕВ2: заканчиваем разработку релиза 2 5. Среда ТЕСТ2: начинаем тестирование релиза 2 у т.д.... Т.е. релизы будут выпускаться со сдвигом друг относительно друга.. в идеале простоя ресурсов в этом случае быть не должно.. Советую так же учитывать, что при разработке нескольких больших проектов на одной базе ДЕВ разработчики могут не ужиться (будут дорабатывать одни и теже объекты и т.п), так что, возможно баз разработки придется делать еще больше, при этом перед тестированием все проекты придется "скрещивать" между собой в один релиз... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 12:09 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
ну в общем, выше всё сказано, если шанс возникновения перечисленных рисков мал, то можно и так оставить, но пару тройку стендов, прозапас, я бы имел ввиду. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 14:24 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
vot_takoyDexterI, Предполагаю что все доработки и стабилизации будут на этапе dev и test среды, т.е. после апрува ответственных лиц, продукт будет выкатываться в uat... Система достаточно масштабны ритейл...Обучение новым фичам в uat среде, т.е. к дев и тесту бизнеса вообще не будет, в uat предпологается что ит практически не будет... На счет новых релизов согласен, есть затык, его я не совсем учел...:( Как тогда быть? Кстати если это крупный ретейл, и есть клиентская часть, то можно бы подумать еще и о стенде тестирования раската .. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2014, 17:18 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
DexterIvot_takoyDexterI, Предполагаю что все доработки и стабилизации будут на этапе dev и test среды, т.е. после апрува ответственных лиц, продукт будет выкатываться в uat... Система достаточно масштабны ритейл...Обучение новым фичам в uat среде, т.е. к дев и тесту бизнеса вообще не будет, в uat предпологается что ит практически не будет... На счет новых релизов согласен, есть затык, его я не совсем учел...:( Как тогда быть? Зависит от релизной политики... ДЕВы и ТЕСТы надо умножать на количество релизов находящихся в производстве.. Например, имеет 2 релиза в производстве: Момент времени T1: 1. Среда ДЕВ1: заканчиваем разработку релиза 1 2. Среда ТЕСТ1: начинаем тестирование релиза 1 3. Среда ДЕВ2: начинаем разработку Релиза 2 Момент времени T2: 1. Среда ДЕВ1: начинаем разработку релиза 3 2. Среда ТЕСТ1: Заканчиваем тестирование релиза 1 3. Среда UAT: начинаем UAT релиза 1 4. Среда ДЕВ2: заканчиваем разработку релиза 2 5. Среда ТЕСТ2: начинаем тестирование релиза 2 у т.д.... Т.е. релизы будут выпускаться со сдвигом друг относительно друга.. в идеале простоя ресурсов в этом случае быть не должно.. Советую так же учитывать, что при разработке нескольких больших проектов на одной базе ДЕВ разработчики могут не ужиться (будут дорабатывать одни и теже объекты и т.п), так что, возможно баз разработки придется делать еще больше, при этом перед тестированием все проекты придется "скрещивать" между собой в один релиз... Все зависит от. На практике всегда бывает так что релиз 1 и релиз 2 имеют НЕПЕРЕСЕКАЮЩИЙСЯ функционал и могут жить на одном стенде. У нас таких релизов живут параллельно ДЕСЯТКИ !! И все работает. Пересекающийся функционал естественно ждет попадания в прод. Но у нас это быстро. В схеме же с несколькими девами - гораздо проще поиметь проблем с их рассинхронизацией. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2014, 13:44 |
|
Тестовые стенды.
|
|||
---|---|---|---|
#18+
vot_takoyТоварищи, Может быть вопрос не совсем сюда, но тем не менее, подскажите пожалуйста как лучше постороить тестовую инфраструктуру. Пока мне видеться так: DEV среда - для разработчиков. Test среда - для тестировщиков. UAT - для тестирования бизнесом. Prod - он же prod. Какие слабые места в данной инфраструктуре? Или что я упускаю из виду. Спасибо :) Все ок, но надо проработать несколько ньюансов перед работой: 1. Какие данные будут лежать на каждой среде. Если на деве - левые и объемы маленькие, на тесте - тестовые и тоже мало, то где проводить нагрузочное? То есть надо тогда решить что на тесте будут объемы приближенные к боевым - и тогда там и мощности должны быть боевые, либо боевые данные только на UAT среде и тогда там придется нагрузочное проводить! 2. Синхронизация данных между средами. Как и когда -регламент. 3. САМОЕ ГЛАВНОЕ - не допускать хотфиксов сразу на прод, в обход остальных. Точнее они-то по любому будут, но строго следить, чтобы все хотфиксы обязательно! попадали на все среды!! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2014, 14:06 |
|
|
start [/forum/topic.php?fid=36&gotonew=1&tid=1554645]: |
0ms |
get settings: |
22ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
12ms |
get first new msg: |
73ms |
get forum data: |
3ms |
get page messages: |
215ms |
get tp. blocked users: |
2ms |
others: | 385ms |
total: | 780ms |
0 / 0 |