Глава 9. Как пережить фазы разработки и опытной эксплуатации
9.1.Сколько и каких баз нужно в проекте на фазе разработки
К началу фазы «Разработка» проект внедрения ERP-системы успешно прошел путь концептуального и архитектурного проектирования, имеется настроенный прототип, но не все в нем получается покрыть текущей функциональностью системы, требуется доработать систему, устранить функциональные разрывы. К началу фазы «Разработка» считаем, что все потребные доработки выявлены и описаны в документе «Технический проект», спланирована последовательность работ, остается только все это окончательно формализовать в технических заданиях, согласовать с заказчиком и сделать.
Прежде чем начинать активную разработку, нужно задаться вопросом организации совместной работы специалистов (разработчиков и консультантов исполнителя, ключевых сотрудников заказчика), минимизировать ситуации попадания непротестированного функционала на рабочую версию к конечным пользователям.
Рассмотрим варианты инфраструктуры из информационных баз для разработки, тестирования и эксплуатации. Выбор подхода зависит от бюджета проекта и выбора проектной команды (как привыкли, как хотят минимизировать риски). Возможны подходы от максимальных по числу используемых баз до минималистических:
- 4 базы: разработка – тестирование – мастер – рабочая;
- 3 базы: разработка и тестирование – мастер – рабочая;
- 2 базы: разработка и тестирование – рабочая.
Явно опасный в использовании вариант, когда информационная база развернута в единственном экземпляре, она же рабочая база пользователей, она же база для тестирования и разработки, детально рассматривать не будем – этот не подход для внедрения ERP-системы.
Подход «разработка – тестирование – мастер – рабочая».
Рис. 9.1. Подход «разработка – тестирование – мастер – рабочая»
При таком способе используется 4 базы:
- База разработки – в нее подключаются разработчики, получают срез конфигурации из общего хранилища, закладывают туда свои доработки, устраняют конфликты и пересечения в коде с другими разработчиками, проводят отладку (возможно, запуск автотестов) и затем переносят проверенные наработки в базу для тестирования.
- Тестовая база – в нее подгружаются прошедшие отладку модификации, в этой базе работают консультанты, настраивают и тестируют учетную модель системы, тестируют существующий и доработанный функционал. Ключевые сотрудники заказчика изучают и тестируют новый функционал. Прошедшие тестирование и утверждение модификации переносятся дальше на мастер-версию.
- Мастер-версия – конфигурация для консолидации прошедших тестирование и запланированных к переносу на рабочую базу в данный релиз модификаций, а также база для финализации настроек учетной модели системы. Наиболее стабильная версия в сравнении с версией тестирования, где может быть еще что-то не прошедшее тесты. «Мастер» – это будущая конфигурация рабочей базы, куда конфигурация переносится целиком, а не по избранным модификациям. На этой базе может проходить финальное тестирование переносимых модификаций и общее регрессионное тестирование на целостность замкнутого цикла учета и бизнес-процессов.
- Рабочая база – база в эксплуатации, в которой работают конечные пользователи с реальными учетными данными. Тестирование и разработка в этой базе под запретом.
Подход «разработка и тестирование – мастер – рабочая».
Рис. 9.2. Подход «разработка и тестирование – мастер – рабочая»
При таком подходе используется 3 базы:
- База разработки и тестирования – в нее подключаются разработчики, получают срез конфигурации из общего хранилища, закладывают туда свои доработки, устраняют конфликты и пересечения в коде с другими разработчиками, в этой же базе работают консультанты, настраивают и тестируют учетную модель системы, тестируют существующий и доработанный функционал. Ключевые сотрудники заказчика изучают и тестируют новый функционал. Прошедшие тестирование модификации переносятся дальше на мастер-версию.
- Мастер-версия – аналогично варианту из 4 баз.
- Рабочая база – аналогично варианту из 4 баз.
Объединение разработки и тестирования, с одной стороны, оптимизирует работу, убирая шаг (и трудозатраты) переноса модификаций в дополнительную базу, с другой – привносит в процесс временное состояние базы, когда тестировать невозможно, т. к. «все разломано», а также потенциальные потери данных настроек для тестирования или частичную потерю данных документов или регистров.
Подход «разработка и тестирование – рабочая».
Рис. 9.3. Подход «разработка и тестирование – рабочая»
При таком подходе используется 2 базы:
- База разработки и тестирования – в нее подключаются разработчики, получают срез конфигурации из общего хранилища, закладывают туда свои доработки, устраняют конфликты и пересечения в коде с другими разработчиками, в этой же базе работают консультанты, настраивают и тестируют учетную модель системы, тестируют существующий и доработанный функционал. Ключевые сотрудники заказчика изучают и тестируют новый функционал. Прошедшие тестирование модификации переносятся дальше на рабочую базу.
- Рабочая база – аналогично варианту из 4 баз.
В этом подходе фокус предварительного тестирования и отладки может быть вынесен на локальные базы разработчиков, туда же могут заходить тестировщики (или брать копию к себе для тестов). Тогда итоговая сборка общего хранилища может быть достаточно стабильна, но в любом случае «мастер» не заменяет, т. к. может содержать лишние для переноса на рабочую базу модификации, не согласованные к переносу на рабочую базу в этот пул обновления. Поэтому при таком подходе на рабочую базу переносить целиком конфигурацию затруднительно – нужно выделять период на стабилизацию, вводить мораторий на перенос с локальных версий модификаций, которые не входят в данный релиз к переносу на рабочую базу.
Условно, при этом подходе все участники знают график, когда будет сборка версии, поэтому за некоторое время до этого происходит остановка помещения изменений в хранилище, наступает мораторий на изменения и консультанты тестируют, проводятся регресс-тесты (автоматические или ручные). Версия стабилизируется, вносятся только исправления ошибок. После отмашки, что версия стабильна, рабочая база получает изменения из хранилища разработки и тестирования и обновляется. После чего мораторий снимается до сборки следующего билда. Такой подход приводит к паузам, когда разработчики не могут поместить в хранилище конфигурации новые модификации, а тестировщики – начать их тестировать, пока идут процессы стабилизации и тестов.
Использование версии «мастер» для сборки готовых модификаций позволяет исключить ошибки ручного переноса на рабочую базу сложных модификаций, дает время на тестирование результата, а не сразу влияет на работу конечных пользователей. Ошибки уровня «ой, я не тот код перенес, а нужный вообще забыл» – это частые ошибки, связанные с невнимательностью и просто человеческим фактором. Поэтому когда на тестовой базе все работает, то это совсем не значит, что с первого раза все заработает после переноса на «мастер» или сразу на рабочую базу. Если для «мастера» есть время выявить проблемы без последствий для реальной работы и рабочих данных, то такие ошибки (пусть даже они быстро исправляются «допереносом забытого») на рабочей базе могут порождать проблемы, которые потребуют значительных усилий на ликвидацию последствий: развал данных потребует отката базы из бэкапа или сложных обработок восстановления данных. Поэтому наличие промежуточной (относительно тестовой версии) стабильной сборки, близкой к рабочей конфигурации, – это залог минимизации таких проблем.
Во всех трех подходах заявлено, что на рабочей базе нет разработки и тестирования. При этом возможны ситуации критичных ошибок, которые исправлять по длительной процедуре (через цепочку конфигураций «разработка – тестирование – мастер» и замену всей рабочей конфигурации целиком) сложно, т. к. нет достаточно времени для этого, работа пользователей стоит. Такие исключения могут приводить к внесению исправлений (проверенных, очевидно, предварительно на тестовой версии) сразу в рабочую базу. Эти же исправления ошибок далее проходят весь пусть миграции по всем базам до мастер-версии и при следующей замене конфигурации с «мастера» на рабочую базу не должны потеряться.
Некоторые ситуации, которые требуют отладки для поиска и исправления ошибок, воспроизводятся только на данных рабочей базы. Нужно снимать с нее копию и заменять периодически базу тестирования свежими данными с рабочей базы. Если параллельно с этим идет настройка данных и тестирование прототипа настроек для других этапов проекта, еще не перенесенных на рабочую базу, то такая замена данных на текущие данные из рабочей базы приводит к потере тестовых настроек. Мы приходим к тому, что баз может стать еще больше, т. к. может потребоваться иметь тестовую базу в двух версиях и нужно время на перенос настроек в обновленную рабочими данными тестовую базу из старой тестовой базы.
Рекомендуется в разных базах делать какие-то отличия: менять заголовки, цвет стилей оформления интерфейса (платформа «1С» это позволяет) – чтобы специалисты визуально, на глаз определяли, что это за база, и случайно не тестировали в рабочей базе. Также стоит отобрать полные права на рабочей базе у разработчиков и консультантов – это тоже хороший способ для защиты от «ой, я перепутал базы». Сделать специальный логин или выдавать права по необходимости. Когда баз много – их будут путать обязательно.
Чем больше баз используется, тем больше накладных расходов на миграцию данных и модификаций между ними возникает, а также растут требования к аппаратной части, особенно с ростом объема рабочей базы. Для получения копии рабочей базы для тестирования при значительном ее объеме потребуется аппаратное обеспечение для стенда тестирования такого же уровня, как для рабочей базы. Поэтому выбор того или иного подхода зависит не только от желания проектной команды, но и от возможностей бюджета проекта: в нем должно быть заложено достаточное аппаратное обеспечение, поддерживающее разработку по цепочке из нескольких баз.
В самом начале фазы «Разработка» может не быть рабочей базы: еще не закуплено оборудование, не готово к развертыванию базы в ее промышленной конфигурации. На ранней стадии фазы это допустимо. Обучение можно проводить на тестовой или мастер-базе, данных еще мало, требования к аппаратной части серверов для разработки ниже, чем для рабочей системы на множество пользователей. Но в какой-то момент рабочая база будет нужна в ее итоговой целевой конфигурации, на рабочих серверах, а задержки настройки серверной аппаратуры могут стать рисками проекта и повлиять на сдвиг сроков начала опытной эксплуатации.
Серверное оборудование заказывает заказчик, поставляет его третья сторона для проекта автоматизации, а сроки из-за задержек аппаратуры и ее настройки «поедут» у исполнителя.
При использовании облачных технологий и (или) виртуальных машин снижается зависимость от аппаратного обеспечения. Тестовые стенды и конфигурация разработки могут разворачиваться на виртуальных серверах в локальной сети или облаках. При частой поставке и сборке билдов на помощь проектной команде приходят практики DevOps.
DevOps (акроним от англ. development и operations, произносится как «девопс») – набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов. DevOps базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на помощь организациям быстрее создавать и обновлять программные продукты и услуги.
Организация миграции данных для тестирования с рабочей базы, обновление из хранилища конфигурации разработки и тестирования, обновление рабочей базы из конфигурации мастера – все это можно (и нужно) автоматизировать соответствующими скриптами, что минимизирует ручной труд (и ошибки, связанные с человеческим фактором).
Еще один важный вопрос – это выбор версии, на которой начинать разработку и настраивать учетную модель прототипа системы автоматизации. Например, у 1С:ERP есть ознакомительные версии, а есть поддерживаемые предыдущие подредакции системы. Для уже внедренного проекта переходить на ознакомительную версию смысла не имеет (если там не заявлен требуемый функционал, критичный для работы, конечно). А вот для нового проекта внедрения нужно выбирать и переходить на актуальную версию системы, пусть и в ознакомительном статусе. Потом будет проще обновляться, нет дополнительных работ по переводу проекта, готового к запуску, со старой подредакции в конце проекта (ее могут снять с поддержки в процессе проекта), когда все уже протестировано и запущено, и сразу доступна вся новая функциональность. Нужно соотносить планы проекта внедрения с планами выпуска новых версий ERP-системы, закладывать риски.
