Представьте, что ваш продукт уже готов и внедрен в эксплуатацию. Все замечательно работает, но при этом с течением времени у вас возникает потребность подправить некоторые детали в системе. Вы обращаетесь к разработчику, он с пониманием кивает – внедрить можно без проблем. Но при этом возникает очень важный вопрос. Сразу внедрять на боевой проект? А если будут критические ошибки? Это может парализовать работу всей системы. Как быть?
Как всегда все очень просто! Надо использовать несколько экземпляров приложения. На мой взгляд оптимальным будет следующее распределение:
- Приложение для разработчиков. Здесь разработчики вносят свои изменения. Сами тестируют, либо тестировщики от команды разработки. Клиенты по сути эту часть не тестируют, максимум они просто могут смотреть как работает какой-то разработанный функционал.
- Приложение для бизнес тестирования. Законченный кусок разработанной системы необходимо тестировать бизнес-подразделением заказчика. Это коренным образом отличается от тестирования разработчиками. На этом этапе может выясниться, что бизнес-логика приложения не учитывает каких- то важных элементов, или программой просто неудобно пользоваться. Именно конечные пользователи лучшие тестировщики. Они лучше всех знают как должна работать программа, хотя бы потому, что они больше всего с ней работают.
- Производственная среда. Приложение работает уже в реальных бизнес-процессах предприятия. Здесь работают те же самые люди, что и в п.2. Но это уже не тестирование,в реальная работа в системе.
Технически лучше всего организовать эти 3 уровня как поддомены. Например, dev, test, prod.
При этом хорошо бы иметь разные логины и пароли для разных уровней. Это уменьшит вероятность кражи и искажения данных в боевой базе данных.
Подобная схема уменьшит проблемы с неожиданным поведением программы. Минусом данной схемы является более долгая процедура внедрения новых изменений. Но, если система работает с финансами или другими критически важными данными, такая схема является предпочтительной.
Как вы в данный момент управляете процессами сопровождения своей системы?
Рекомендуем изучить статью о коммуникации в автоматизированной системе.