Содержание:
1. Обновление 1С: Инструкция и общая схема решения
3. Результат оценки трудоемкости обновления
Программы 1С нуждаются в регулярном обновлении: они адаптируются к изменениям законодательства, исправляют ошибки, подтягивают новые технологии. Если с типовыми, неизмененными конфигурациями все достаточно просто – они содержат встроенные механизмы «поддержки» вплоть до возможности полностью автоматического обновления, то с измененными конфигурациями 1С процесс обновления может быть достаточно трудоемким и, следовательно, его желательно спланировать.
Установка обновлений 1С: Условия задачи
Рассмотрим планирование обновления и оценку его трудоемкости на следующем примере:
· На базе типового релиза конфигурации, в нашем случае это обновление Управление торговлей 11.2.3.202
· были внесены изменения «под заказчика» общим объемом 2000 чел./часов.
· К моменту, когда созрела необходимость обновления, номер актуального типового релиза составлял 11.4.5.118.
Дополнительное условие:
· Описания внесенных изменений (в объеме 2000 чел./час) нет (для управляемых форм это не критично, для обычных форм – критично).
Пошаговая инструкция, как обновить версию 1С:
1. Выделить и классифицировать изменения конфигурации
1.1. В первую очередь выделить изменения типовых данных – изменения свойств реквизитов типовых объектов. Типовые релизы при обновлении будут приводить эти реквизиты к «типовой» форме, и если это не учесть, то такие измененные данные можно потерять.
1.2. Выделить «новые» данные – дополнительные объекты метаданных, дополнительные реквизиты типовых объектов. Типовые релизы при обновлении их трогать не будут. Хотя контролировать их сохранность при переходе от релиза к релизу нужно. Поскольку в «следующем» типовом релизе могут появится объекты/реквизиты с «вашим» наименованием, и тогда они будут «затерты», т.е. потеряны.
1.3. Изменения функционала – программного кода. Перенос этих изменений наиболее трудоемок, но переносить их в промежуточные релизы нет необходимости, достаточно сделать это один раз на финальном релизе. При таком подходе промежуточные обновления будут нерабочими в части нетипового функционала, но это и не требуется – рабочим должен быть только финальный релиз.
2. При движении по промежуточным релизам из цепочки обновлений:
2.1. Перед накатыванием очередного промежуточного типового релиза внести в него «изменения типовых данных».
2.2. Проверить, нет ли пересечений типовых данных и «новых данных».
2.3. Полученный промежуточный типовой релиз накатывать на рабочую базу.
3. В финальный релиз:
3.1. Внести «изменения функционала».
3.2. Накатить полученный финальный релиз.
3.3. В результате получим обновленную работоспособную базу – «целевой измененный релиз».
2. Этапы обновления
1. Построить цепочку релизов обновления 1С:УТ и определить количество промежуточных обновлений.
Фирма «1С» и ее партнеры выпускают большое количество обновлений. Некоторые из них можно пропустить, а некоторые нельзя. Для построения цепочки обновлений можно воспользоваться, например, ресурсом «Грань IT».
В нашем случае:
Текущий релиз: 11.2.3.202
Целевой релиз: 11.4.5.118
Требуется выполнить 13 обновлений: 11.2.3.213, 11.2.3.242, 11.3.2.193, 11.3.2.218, 11.3.3.163, 11.3.3.196, 11.3.3.231, 11.3.4.67, 11.3.4.112, 11.3.4.153, 11.3.4.221, 11.3.4.228, 11.4.5.118
2. Определить необходимость обновления платформы.
Для этого сравниваем текущий релиз платформы с номером релиза, который требуется для целевого релиза конфигурации.
Текущий релиз платформы: 8.3.12.1616
Требуемый релиз платформы: 8.3.12.1469 (и выше)
Следовательно, нам требуется обновить платформу 1С.
3. Выделить и классифицировать изменения конфигурации.
3.1. Что ищем (см. раздел «Общая схема решения»)
3.1.1. Изменения типовых данных (прил.1)
3.1.2. Новые данные
3.1.3. Изменения функционала (прил.2)
3.2. Где ищем изменения
3.2.1. В метаданных основной конфигурации
3.2.2. В расширениях конфигурации
3.2.3. Во внешних печатных формах/отчетах/обработках
3.2.4. В типовых печатных формах
4. Оценить трудоемкость обновления.
4.1. Трудоемкость переноса настроек (функционала) в финальный релиз конфигурации
Здесь поможет встроенный механизм «сравнения конфигураций», который выдает описание изменений (прил.2), трудоемкость переноса которых уже можно оценить. Особо нужно отметить изменения в формах: если для управляемых форм механизм «сравнения конфигураций» выдаст описание, то для обычных форм – нет. И эти изменения придется выбирать вручную.
4.2. Трудоемкость промежуточных обновлений с сохранением нетиповых данных, но без переноса нетипового функционала
4.2.1. Оценить время одного промежуточного обновления. Для этого можно провести тестовый замер на одном переходе.
4.2.2. Учесть количество промежуточных обновлений (п.1)
4.2.3. Учесть количество изменений редакции, такие переходы, как правило, более продолжительны по времени. В нашем примере два изменения редакции: 2.2 à 2.3 и 2.3 à 2.4.
4.3. Трудоемкость адаптации расширений конфигурации
Здесь сложно дать какие-то формализованные рекомендации по оценке. Нужно анализировать код и понять, насколько он независим от типовых настроек. Косвенно можно оценить по объему объектов и строк программного кода в расширениях.
4.4. Трудоемкость адаптации внешних печатных форм/отчетов/обработок
Ситуация с оценкой здесь схожа с расширениями.
4.5. Трудоемкость тестирования и отладки
4.5.1. Построение Чек-листов для тестов
4.5.2. Проведение проверок
4.5.3. Проведение отладки
5. Построение календарного план-графика обновлений.
Здесь важно совместить необходимость вывода базы из эксплуатации на время обновления (п.4.2) и сохранение работоспособности предприятия. В нашем примере для наложения всех обновлений необходимо было вывести рабочую базу из эксплуатации на 18 час. Если такой интервал не приемлем, тогда обновление следует разбивать на несколько частей и, соответственно, готовить несколько промежуточных работоспособных релизов – переносить в них нетиповой функционал. Например, в нашем случае делим обновление на два этапа по 9 часов: первая ночь обновления (9 час.) – днем база работает – вторая ночь обновления (9 час.) – днем и далее база работает.
6. Получение финального релиза конфигурации с перенесенным нетиповым функционалом. Или несколько финальных релизов, если согласно п.5 требуется разбить обновление на несколько этапов. В конце каждого из которых должна быть получена работоспособная база.
6.1. Адаптация расширений
6.2. Адаптация внешних печатных форм/отчетов/обработок
7. Тестовое обновление (на копии БД)
7.1. Обновление платформы 1С до требуемого релиза (см.п.2)
7.2. Промежуточные обновления
7.3. Финальное обновление
8. Тестирование обновленного релиза на копии БД, отладка
9. Обновление рабочей БД
9.1. Промежуточные обновления
3. Результат оценки трудоемкости обновления
4. Заключение
Были рассмотрены подходы к планированию и оценке трудоемкости «сложных» обновлений сильно измененных конфигураций 1С.
Трудоемкость подготовки такой оценки составила 20 час.
Следует отметить, что за кадром остались организационные моменты, такие, например, как создание рабочих групп для тестирования, обучение пользователей измененному типовому функционалу и т.п. Их также необходимо включать в планирование и оценку. Не учтены также резервы на риски.
Напомню, что обновлялась конфигурация, в которую внесено изменений на 2000 час. Трудоемкость ее обновления составила порядка 200 час., т.е. соотношение примерно 1/10. Пожалуй, такое соотношение близко к максимальному. Факторы, которые помогут снизить сложность обновлений:
· По возможности не смешивать измененный программный код с типовым, выносить изменения программного кода в отдельные программные модули, подписки на события, в механизм расширения конфигураций и т.п.
· Выбрать такую частоту обновлений, при которой количество промежуточных релизов и, соответственно, время вывода рабочей базы из эксплуатации будут приемлемым. Например, успевать накатить обновление за одну ночь, чтобы на следующий день база была работоспособной.
· Документировать вносимые изменения с обязательным указанием целей этих изменений.
Последний фактор возможно и не снизит трудоемкость ближайшего обновления, но имеет стратегический характер. Дело в том, что:
· Следующие типовые релизы могут включать в себя смысл тех изменений, которые вы внесли сами, и тогда «ваши» решения нужно просто исключать из конфигурации и переходить на типовые.
· Задачи, которые решались вашими «специальными» настройками, могут просто стать неактуальными для компании. Тогда их тоже следует «законсервировать» либо полностью вынести из настроек конфигурации, чтобы в дальнейшем не тратиться на их сопровождение.
В обоих этих случаях требуется понимание «а зачем эти изменения были внесены».
В качестве примера использовалась обновление Управление торговлей. Но все описанное универсально и применимо для любых измененных конфигураций 1С.
Приложение 1
Пример описания изменения типовых данных для переноса в промежуточных обновлениях
1. Справочник.Номенклатура.Реквизит.ОбъемЧислитель Число(15,4)
2. Справочник.Производители.ДлинаКода Длина кода = 11
3. Документ.ПередачаТоваровМеждуОрганизациями
3.1. ЦенаВключаетНДС Истина
3.2. ПередачаПодДеятельность ПеречислениеСсылка.ТипыНалогообложенияНДС.ПродажаОблагаетсяНДС
4. Документ.РасходныйКассовыйОрдер.Реквизит.ДокументОснование
4.1. Доб.тип. ДокументСсылка.Инагро_ЗатратыТС
5. РегистрСведений.ТоварыКДоставке.Измерение.Накладная
6. РегистрСведений.ШтрихкодыНоменклатуры.Измерение.УникальныйИдентификаторЗаписи
Приложение 2
Пример описания изменений конфигурации и оценки трудоемкости их переноса
Специалист компании ООО «Кодерлайн»
Игорь Борисенко.
