Categories: Разное

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

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

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

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

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

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

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

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

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

Recent Posts

Форма теста внешних действий #falconstart

Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…

2 недели ago

Концепция внешних действий – telegram, email, уведомления на сайте

Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…

2 недели ago

Работа с JSON в SQL #falconstart

После выполнения действий в SQL на клиенте иногда возникает необходимость что-то обновить или сделать. Для…

3 недели ago

Форма с отправкой запроса API. Тестирование исходящих запросов #falconstart

Вы можете обратиться к внешним API через использование Внешних действий (код apirequest, использование описано в…

3 недели ago

Таблица Trace для отслеживания событий на сайте

В системной таблице as_trace хранятся данные по работе приложения. Поле code определяет тип события: DBLREQ…

3 недели ago

Работа с ошибками в системе. Генерация отчета по ошибкам #falconstart

Рассмотрим механизм анализа ошибок, как это всё работает, и как его использовать. Когда происходит ошибка…

4 недели ago