Управление разработкой

На написание данного поста меня натолкнула беседа с моим коллегой на тему динамического обновления в 1с. Если очень коротко, то у моего коллеги возникла проблема после выполнения динамического обновления базы (примерно такая: Ошибка СУБД: ERROR:  relation «_reference5029» does not exist).  Лично я сам несколько раз сталкивался с подобными проблемами. Большинство проблем которые могут возникнуть хорошо описываются тут. Со слов Вячеслава вообще не стоит использовать динамическое обновление. От части я с ним согласен, но предлагаю посмотреть на проблемы с другой стороны. Итак, наш подход к этой проблеме. Хочу добавить, что мы не придумали ничего нового и оригинального. Мы просто упорядочили этот процесс.

Динамическое обновление, безусловно, очень удобный инструмент реализуемый компанией 1С в продуктах 1С:Предприятие начиная с версии 8.1. Но насколько часто приходится его использовать в реальной жизни? Мой коллега утверждал, что используют этот механизм они (их отдел) очень часто. Мы же у себя используем его довольно редко. Почему? У нас разные подходы к разработке.

По моему глубокому убеждению необходимость динамического обновления возникает в 90% случаях в связи с досадной ошибкой в коде. Разработчик не достаточно проверил то, что он написал. Внес изменения в рабочую конфигурацию и в какой-то момент (как правило буквально спустя 10 минут) возникла ошибка. Как утверждал мой коллега у них ситуация иная и у них возникает реальная необходимость добавления нового функционала в течении рабочего дня, как говорится «здесь и сейчас». Возможно, в отдельных организациях имеют место быть такие случаи, но как я уже писал выше, проблема скорее всего в подходе к разработке.

Буквально несколько месяцев назад меня посетила мысль, что необходимо упорядочить нашу работку по разработке. Я начал гуглить на тему, а как это делают другие. Мне стало интересно, а как же это происходит в крупных проектах. Скорее всего уже все придумали до меня, и мне надо просто использовать лучшие практики. Отличным примером крупного проекта с описанием организации разработки, по моему является проект debian. Внимательно ознакомившись с организацией разработки в этом проекте мы решили, что основных идеи для нас 3. Этот «система веток», «система выпусков (релизов)» и «организация коммитов» (внесения изменений в основную конфигурацию). Своими словами суть идей очень простая. Для разработки используются две ветки стабильная и нестабильная (в debian их 3). Через строго определенный период времени из одной ветки происходит перенос в другую — выпуск (релиз). За перенос отвечает один человек. Вот собственно и все, а вы ждали чего-то супер нового? 🙂

Итак, как мы это переложили на нашу разработку на 1с. У нас 2 ветки и недельная система выпусков.

  • Рабочая конфигурация (стабильная ветка) расположена на рабочем сервере;
  • Разрабатываемая конфигурация (нестабильная ветка) расположена на резервном сервере.

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

  1. Рабочая база довольно большого размера и работать с ней локально будет не комфортно по скорости;
  2. То, что вы разработали и проверили на локальной базе, может в корне отличаться (в первую очередь по скорости) с тем, что будет в рабочей базе. Кроме того надо учитывать особенности разработки под postgres (сортировка в первую очередь);
  3. Моделирование почти реальных условий работы.

Как выглядит весь процесс?

  1. Все изменения и обновления изначально вносятся в нестабильную ветку (конфигурацию);
  2. В течении недели идет работа с нестабильной веткой (разработка, тестирование);
  3. Каждую пятницу в 15-00 все изменения внесенные в нестабильную ветку «замораживаются»;
  4. Человеком ответственным за обновление принимается решение о том, что можно вносить в стабильную ветку, а что нет;
  5. Человек ответственный за обновление выполняет объединение веток (конфигураций).

Примечание:

Тестирование как правило заключается в работе на контрольном примере + проведении документов  за текущий месяц. Проведение выполняется для контроля того, что изменение не затронуло другие подсистемы.

Таким образом все изменения функциональности происходят в определенное время. Да, мы не вносим изменения по требованию пользователей (за исключением действительно жизненно необходимых случаев). К примеру если сотрудник запросил определенные изменения в четверг и это требует значительно времени на разработку, то требуемую функциональность он (сотрудник) увидит только в следующем выпуске (в следующую пятницу после 17-00). Любое внештатное изменение функционала конфигурации, на мой взгляд, говорит об отсутствии планировании в разработке.

В принципе на этом все. Может быть получилось несколько сумбурно, тк у нас нет задокументированной процедуры (да, все на словах). Возможно этот пост будет отправной точкой для разработки еще более формальной и задокументированной процедуры.

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

А как у вас организован подобный процесс? Давайте в комментарии…

Управление разработкой: 9 комментариев

  1. Как решается вопрос синхронизации данных для девелоперской и производственной БД? Соответственно, как организованы поиск и исправление свежих багов?

    Для времени релизов мы завели жесткое правило: вечером и перед выходными ничего нового не выкладывать. Только в обед. Вызвано тем, что организация работает в режиме 24×7, а практика, когда кто-то что-то выложил в восемь вечера и быстро ушёл домой, а ближе к полуночи валится часть системы, быстро всем надоела.

  2. Сами данные между собой никак не синхронизируются. Если речь идет о синхронизации конфигураций, то они объединяются в отведенное время. Все исправления ошибок вносятся в нестабильную ветку и далее в зависимости от ошибки либо все изменения вносятся в час Ч или по мере возможности. Синхронизация веток в обед — это правильное решение. Возможно нам тоже следует изменить временные рамки.

  3. Откуда берётся база для разработки: это еженедельный снапшот рабочей после слияния или параллельная независимая версия?

  4. Лев, Антон говорит про перекачку данных в тестовую БД
    Т.е. вопрос в том, что при активная разработке в тестовой, метаданные отличаются, так что просто перекачать данные (документы и прочее) для актуализации тестовой БД затруднительно.

    Лично это вижу как стабилизация тестового релиза накат ВСЕХ нововведений, архивация тестовой БД и перекачка с рабочей (возможно через бэкап рабочей и рестор на тестовую средствами postgresql, возможно выгрузками).

    Синхронизация рабочей и тестовой баз по данным в общем случае нереальна.

  5. Вообще в debian все правильно сделано… я думаю надо именно так и перекладывать

    stable — рабочая ветка

    unstable — ветка для разработки в понимании Льва

    testing в общем случае представляет собой ночной снапшот рабочей базы. Используется для тестирования как самих наработок на реальных данных, так и их наката на боевую базу.

    Смысл такой: разработка ведется в unstable. В определенный момент, когда надо переносить наработки в testing загружается актуальная база (ночной бэкап stable). После этого наработки накатываются на testing в которой и проходят основные тесты.

    Плюсы:
    — можно попробовать как будет все накатываться на рабочую БД
    — можно протестировать на актуальных данных
    — можно сформировать минимальный пакет для обновлений и обойти какие-то грабли

  6. А если ещё автоматизировать тестирование (и, возможно, обновление)…

  7. Вообще вопрос автоматизации тестирования очень интересная тема.

    Хотя судя по статье (http://www.software-testing.ru/library/testing/general-testing/562-1-8-) инструмент Сценарное тестирование имеет ограниченную применимость в вопросе регрессионного тестирования кода в 1С, все равно, это лучше чем ничего.

    Интересно, какие есть наработки по тестированию 1С как в плане кода, так и в плане регламента?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *