Categories: Разное

Схема сопровождения продукта по автоматизации

Представьте, что ваш продукт уже готов и внедрен в эксплуатацию. Все замечательно работает, но при этом с течением времени у вас возникает потребность подправить некоторые детали в системе. Вы обращаетесь к разработчику, он с пониманием кивает – внедрить можно без проблем. Но при этом возникает очень важный вопрос. Сразу внедрять на боевой проект? А если будут критические ошибки? Это может парализовать работу всей системы. Как быть?

Как всегда все очень просто! Надо использовать несколько экземпляров приложения. На мой взгляд оптимальным будет следующее распределение:

  1. Приложение для разработчиков. Здесь разработчики вносят свои изменения. Сами тестируют, либо тестировщики от команды разработки. Клиенты по сути эту часть не тестируют, максимум они просто могут смотреть как работает какой-то разработанный функционал.
  2. Приложение для бизнес тестирования. Законченный кусок разработанной системы необходимо тестировать бизнес-подразделением заказчика. Это коренным образом отличается от тестирования разработчиками. На этом этапе может выясниться, что бизнес-логика приложения не учитывает каких- то важных элементов, или программой просто неудобно пользоваться. Именно конечные пользователи лучшие тестировщики. Они лучше всех знают как должна работать программа, хотя бы потому, что они больше всего с ней работают.
  3. Производственная среда. Приложение работает уже в реальных бизнес-процессах предприятия. Здесь работают те же самые люди, что и в п.2. Но это уже не тестирование,в реальная работа в системе.

Технически лучше всего организовать эти 3 уровня как поддомены. Например, dev, test, prod.
При этом хорошо бы иметь разные логины и пароли для разных уровней. Это уменьшит вероятность кражи и искажения данных в боевой базе данных.

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

Как вы в данный момент управляете процессами сопровождения своей системы?

Рекомендуем изучить статью о коммуникации в автоматизированной системе.

Руслан Раянов

Recent Posts

Что важно учесть в системе обработки заказов? Проблемы системы заказов

https://falconspace.ru/blog/sozdanie-sistemy-upravleniya-zakazami-v-vide-lichnykh-kabinetov-na-sayte - Система управления заказами на предприятии. Разработка автоматизированной системы заказов

2 недели ago

Ошибки при запуске маркетплейса

Запуск собственного маркетплейса — это захватывающий, но сложный процесс, который требует внимания к деталям и…

2 недели ago

Что такое онлайн система заказов?

https://falconspace.ru/blog/sozdanie-sistemy-upravleniya-zakazami-v-vide-lichnykh-kabinetov-na-sayte - Система управления заказами на предприятии. Разработка автоматизированной системы заказов

2 недели ago

Причины неудачи it проекта

https://falconspace.ru/blog/chto-delat-kogda-startap-ne-poshel - Причины неудачи it проекта. Как реанимировать веб-проект?

2 недели ago

Меры по обеспечению доступности сайта

https://falconspace.ru/blog/kak-zashchitit-sayt--obespechenie-informacionnoy-bezopasnosti-sayta - Как защитить сайт? Обеспечение информационной безопасности сайта

3 недели ago

Меры по обеспечению целостности информации на сайте

https://falconspace.ru/blog/kak-zashchitit-sayt--obespechenie-informacionnoy-bezopasnosti-sayta - Как защитить сайт? Обеспечение информационной безопасности сайта

4 недели ago