Технология работы с конфигурацией
Меня попросил один хороший товарищ рассказить, как мы организовали работу с конфигурацией при разработке. Чтобы эта информация не пропала, я решил её опубликовать у себя в ЖЖ. Учтите, это не инструкция и не полное описание нашей системы. Это просто небольшой набросок, отражающий фактическую картину.
Графическая схема
Роли участников процесса
Пользователи - простые пользователи, которые работают с основной рабочей базой
Разработчики Синар - сотрудники, которые разрабатывают решения, используемые в Синар
1С - поставщик базового прикладного решения
Администратор хранилища конфигурации - разработчик Синар, имеющий полный доступ к хранилищу конфигурации
Администратор создания файлов поставок - разработчик Синар, имеющий право принимать решение о релизе и создавать файлы поставки
Администратор загрузки файлов поставок - плоьзователь, имеющий право совершать административные действия с основной рабочей базой, в т.ч. загружать обновлять конфигурацию файлом поставок
Разработчик, ответственный за приём обновлений 1С - разработчик Синар, обладающий достаточной квалификацией для обновления конфигурации по файлу обновления от 1С
Описание конфигураций и информационных баз
См. графическую схему.
Стандартная конфигурация УПП. На поддержке 1С. Изменения запрещены. Развёрнута как минимум одна ИБ с этой конфигурацией у разработчика, ответственного за приём обновлений 1С, причём обычно это типовая демонстрационная ИБ. На этой же ИБ же проверяются сообщения об ошибках в типовой конфигурации перед отправкой в службу поддержки.
Конфигурация, которая находится на поддержке 1С с разрешёнными изменениями. Развёрнута у каждого разарботчика Синар в виде пустой ИБ с загруженной конфигурацией (никогда не запускается в режиме "Предприятие"). Связана с хранилищем, а значит основная конфигурация всегда идентична основной рабочей ИБ (это будет видно из процесса работы). Предназначена для нескольких задач: во-первых, служит буфером обмена между хранилищем и ИБ, в которой ведётся разработка, во-вторых именно в этой ИБ формируются файлы поставки. Подробно о происхождении этой ИБ см. "Цикл обновления". По сравнению с типовой конфигурацией 1С, кроме функциональных различий, надо отметить, что изменен идентификатор на УправлениеПроизводственнымПредприятиемСинар, а также изменена информация о поставщике и некоторые другие идентификационные реквизиты "корня" конфигурации.
Основная ИБ. На поддержке Синар без возможности модификации. С ней работают пользователи (разработка в ней не ведётся). Иногда может служить базой для снятия копии для последующего создания информационной базы для разработки.
Конфигурация для разработки. Находится на поддержке Синар с возможностью изменения. Такая ИБ (как минимум одна) развёрнута у каждого разработчика, может содержать копию данных основной ИБ.
Взаимосвязи хранимых конфигурация
Под "данными" в данном абзаце понимается структура конфигурации и её наполнение, а не данные информационных баз!
Из конфигурации 1 в конфигурацию 2 данные попадают через механизм обновления конфигурации поставщика. Т.к. в конфигурации 2 разрешены изменения и она отличается от типовой конфигурации, то обновление происходит со сравнением и объединением и требует достаточно продолжительного времени. (Ответственный - Разработчик, ответственный за приём обновлений 1С)
ИБ с конфигурацией 2 связана с хранилищем, поэтому осуществляется постоянная двусторонняя синхронизация с хранилищем. (Ответственный - Разработчики Синар)
Для подготовки файла поставки, используется ИБ с конфигурацией 2, связанная с хранилищем. Обязательно перед формированием файлов поставки конфигурация обновляется из хранилища. Обязательно полученный файл поставки проверяется на ИБ разработчика с конфигурацией 4. Возможно автоматизированное выполнение скриптом. (Ответственный за создание файлов поставки - Администратор создания файлов поставок, ответственные за формирование версии хранилища - Администратор хранилища конфигурации)
Полученные файлы поставки складываются в общую папку шаблонов обновлений с нумерацией версий по хранилищу конфигурации. Возможно автоматизированное выполнение скриптом. (Ответственный за контроль, архивацию, доступ и т.п. - Администратор создания файлов поставок)
Файлы обновления при помощи механизма обновления конфигурации поставщика загружаются в основную ИБ. В отличие от обновления типовой УПП здесь не происходит сравнения/объединения. Возможно автоматизированное выполнение скриптом. (Ответственный - Администратор загрузки файлов поставок)
Цикл доработки
Расписано достаточно подробно, на самом деле сам процесс достаточно быстрый (но проходит все стадии).
Разработчик Синар разрабатывает некий блок или изменение в ИБ с конфигурацией 4. При этом есть определённые правила оформления кода, рекомендации по разработке и реестр доработок, которые позволяют "не потеряться" этой доработке в конфигурации.
Администратор хранилища конфигурации дополнительно контролирует, что внесенные изменения не разрушат структуру хранилища и конфигурации 2
Разработчик Синар (совместно с Пользователем) осуществляет предварительную проверку разработанного блока в ИБ с конфигурацией 4
В зависимости от харакетра доработки разрабатывается план тестирования
Администратор создания файлов поставок создаёт файл поставки в ИБ с конфигурацией 2
Разработчики Синар тестируют файл поставки по планам тестирования в ИБ с конфигурацией 4
Администратор создания файлов поставок принимает решение о допустимости загрузки файла поставки в рабочую ИБ (конфигурация 3)
Обновление по типовой 1С очень неприятный и сложный момент в работе. И, кстати, спасибо фирме 1С, что она, как может, этот процесс облегчает нам. Где не указано, там действия выполняет Разработчик, ответственный за приём обновлений 1С.
Получается информация от 1С об изменении.
Принимается решение о целесообразности и сроках обновления. Обычно ждём неделю-две, если нет чего-то срочного в обновлении. Иногда обновлять не имеет смысла из-за незначительности изменений (вносятся "аналогичные" изменения по циклу доработки)
Захват всех объектов конфигурации в хранилище. Все разработчики предупреждаются об этом.
Обновление конфигурации 2 по конфигурации 1 через механизм поставок и сравнение-объединение. Очень сложный и творческий процесс. Требуется сохранить всю текущую функциональность, внеся изменения от типовой 1С. Занимает 2-6 дней без сохранения конфигурации. Большой объём ОЗУ и надёжный ИБП - обязательны!
Сохранение конфигурации 2 в обновлённом варианте. Хранилище пока не обновляется!
Проверка конфигурации путём "загрузить конфигурацию из файла" на ИБ с конфигурацией 4.
Формирование плана внедрения и планов тестирования.
Обновление версии хранилища. Ни в коем случае эта версия не уходит в рабочую ИБ!
Тестирование версии хранилища всеми разработчиками по планам, по "своим" участкам с привлечением опытных пользователей.
Обновление версии хранилища. Потому что на предыдущем шаге почти гарантированно что-то "всплывает".
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
speshuric) wrote,
