Если вы IT специалист, в вашей компании используют 1С версии 8 и вы хотите как-то упорядочить процесс внесения изменений в рабочую систему – то вы зашли по адресу. В этой статье я постараюсь поделиться своим опытом по организации изменений в продуктивной системе 1С. В этой статье я расскажу, как решить следующие задачи для бизнеса:

1. Ведения истории изменений
2. Быть уверенным, что в системе применяется изменения по конкретной доработке
3. Минимум простоя бизнеса

Эти 3 пункта – основа политики Change Management для любой компании. Поэтому, если вы озадачены навести порядок в своей компании в этом вопросе – моя статья может вам в этом помочь.

Для решения всех 3-х задач безусловно потребуется комплексный подход, но в целом нам поможет встроенный в 1С механизм работы с конфигурациями – Хранилище конфигураций, Этот механизм предназначен для совместной разработки несколькими программистами, а также для сохранения истории изменений конфигурации. Вот это свойство как раз нам и нужно.

Как работает хранилище? Конечно, из-за терминов, которые использует сама 1С – тут не все так однозначно для «простых смертных», но постараюсь разъяснить «со своей колокольни».

Хранилище конфигураций – сделано в большей степени для разработчиков. И работают они с ним по следующему классическому алгоритму:

• Есть продуктивная конфигурация

Продуктивная система, продуктив, продакшн (производная от англ.  “Productive” и “Production”) – термин, означающий основную рабочую систему, в которой ведется основной актуальный учет хозяйственной деятельности компании. Так же её ещё называют «Боевой системой»

• Для продуктивной конфигурации создается копия – используется она программистом для разработки. Таких копий может быть много – например, у каждого разработчика она своя.
• Создается хранилище конфигураций
• Продуктивная база и базы разработчиков подключаются к хранилищу конфигураций
• Разработчик захватывает из хранилища конфигураций какой-то объект конфигурации и только он может с ним работать. Этих объектов может быть много, или даже все объекты конфигурации. Другие разработчики видят кем захвачен объект и ждут, когда он станет доступен, если им тоже нужен этот же объект.
• Программист, закончив работу, помещает объект в хранилище конфигураций. В хранилище конфигураций фиксируется какой объект был изменен – в случае необходимости эти изменения можно отменить.
• Основную конфигурацию (путем получения конфигурации из хранилища) обновляется из хранилища и плодами разработки уже могут пользоваться рядовые пользователи 1С

Схематично этот процесс изображен на рисунке:

Выглядит красиво, понятно и прозрачно. По этой схеме разработчик должен выполнить доработку в своей конфигурации, протестировать её работоспособность и, убедившись, что он сделал все корректно – выложить свою работу в хранилище конфигураций, откуда свежая конфигурация подтянется продуктивным сервером и радостные пользователи начнут «пожинать плоды разработки». И на первый взгляд можно подумать, что, увеличив количество разработчиков можно во столько же раз увеличить количество разработок. А значит быстрее усовершенствовать систему…

К сожалению, на практике оказывается не все так просто. Чаще всего разработку ведут программисты аутсорсинговых компаний, которые не видят бизнес-процессов компании в целом, да и нет у них времени это изучать. Поэтому они в лучшем случае вникают в малую часть функционала системы, которая, как им кажется, достаточна для выполнения конкретной поставленной им задачи. В итоге заказчик может получить доработку, которая сломает другой механизм в системе. А бывает и такое, что разработчик выдает желаемое за действительное – т.е. думает, что он все сделал, а его разработка «не взлетает». А если такую «горе-разработку» сразу воткнуть на рабочий сервер – можем получить нежелательный эффект в виде простоя бизнеса. А представьте, что будет с конфигурацией если все разработчики так периодически ошибаются – там черт ногу сломит! С такими разработчиками нельзя работать по такой схеме. И не их в том вина – у них жизнь такая 😊

К сожалению, работу программистов нужно проверять. Т.е. должна быть группа компетентных тестировщиков, которые:

• Отлично знают все бизнес-процессы компании
• Отлично знают, как работает система
• Смогут проверить разработку по конкретной заявке
• Смогут проверить смежный механизм, чтобы убедиться, что остальной функционал работает в прежнем режиме

Когда группы тестировщиков нет – её можно собрать из реальных пользователей и попросить на тестовой конфигурации протестировать их основной функционал, с которым они работают в системе. Но на постоянной основе пользователей так эксплуатировать нельзя – у них все же своя работа в компании. Но иногда можно 😉

Если таких специалистов-тестировщиков в компании не много – на первый взгляд это становится узким горлышком на пути внедрения разработки в продуктивной системе. Но, как оказалось – один такой специалист может довольно спокойно контролировать разработку минимум 3-х программистов независимо от объема разработок, которые они делают.

Исходя из вышеизложенного, можно было бы предложить вот такую схему работы:

И, наверное, такая схема тоже имеет право на жизнь, если разработчики работают последовательно. Т.е. пока тестировщик проверяет работу разработчика 1 – этот программист сидит без дела. Остальные программисты в это время могут работать над доработками системы, но только не над теми объектами, которые в данный момент захвачены первым программистом и находятся в стадии предрелизного тестирования. Основной недостаток такой схемы – большая вероятность простоя программиста. Правда, если программист на аутсорсе – он найдет чем заняться. Другой недостаток – тестировщик. Он вынужден поддерживать среду тестирования на каждом экземпляре БД у каждого разработчика.

В наших же реалиях, когда компании работают в режиме «оптимизации затрат», от разработчиков требуют выполнения всех поставленных задач «здесь и сейчас». Кроме того – разные доработки не редко затрагивают одни и те же объекты в системе. Поэтому разные разработчики вынуждены периодически отдавать объекты на редактирование коллегам. В итоге в конфигурации после разработчиков порой им самим трудно разобрать что к чему, и к какой разработке относится, и как исправить ошибку, которая неожиданно проявилась.

Поэтому жизнь продиктовала мне 3-й вариант. Мой принцип в этом плане прост: «Мухи отдельно, котлеты отдельно». А точнее разделяем разработку, тестирование и продуктив:

В данном случае я не стал трогать разработчиков и позволил им работать по своим правилам. Но поставил им условие, чтобы в коде обязательно делали пометки по каким задачам они делают свои доработки: изменяемый кусок кода выделялся разработчиком по принципу парных тегов HTML.

Когда программист выполняет доработку – он сохраняет конфигурацию, помещает её в хранилище разработки. Далее я могу достать их конфигурацию, или сам разработчик выкладывает конфигурацию на файлообменник. На этом основная функция разработчиков закончена – она принципиально не отличается от предыдущих схем.

Теперь перейдем к окружению тестировщика. Оно представляет из себя отдельную конфигурацию, которая является идентичной копией продуктивной системы, и базу данных, которая не обязательно идентична продуктивной, но, при необходимости, можно её обновить из резервной копии продуктивной системы. Тестировщик подгружает конфигурацию разработчика и переносит в свою конфигурацию объекты по одной или нескольким доработкам – ориентируясь на пометки в коде. Благо в 1С для такого переноса реализован достаточно удобный интерфейс. После успешного переноса тестировщик может приступить к тестированию. Может привлечь других тестировщиков, или даже пользователей. Если по ходу тестирования возникают проблемы – составляется список недочетов и отправляется программисту на доработку. Если же замечаний нет – доработку можно готовить к переносу в продуктив. Но уже можно выгрузить конфигурацию из тестовой системы, чтобы заново не выбирать «разработческий мусор» — эта конфигурация будет отличаться от продуктивной ровно на те доработки, которые были протестированы.

«Зачем же в тестовой разработке хранилище конфигураций?» — спросите вы? Да, собственно, оно там не обязательно, но для себя я его создал и получил дополнительные возможности. Во-первых, я могу проследить свои этапы тестирования доработок – в нем я так же, как и в продуктивной системе, вел историю изменений (об этом позже). А во-вторых – функционалом хранилища я могу заморозить тестирование одной доработки и взяться за тестирование другой и быть уверенным, что у меня в конфигурации нет кода по первой доработке. Потом я могу вернуться к тестированию первой доработки и не тратить снова время на вытаскивание нужных кусков кода из конфигурации разработчика.

Теперь пару слов об особенностях продуктивного окружения. Конфигурация продуктивной системы захвачена в хранилище и в такой схеме может получать свои изменения только через конфигурацию обновления. И это сделано для того, чтобы иметь возможность применить обновление продуктивной системы максимально быстро, и практически незаметно для пользователей, оставив всю подготовительную работу за кадром. Т.е. выгруженную конфигурацию из тестовой среды мы загружаем в конфигурацию для обновления, применяем изменения и помещаем конфигурацию в хранилище. В этот момент в истории хранилища делается запись, в которой помечаются объекты, которые были изменены этой новой конфигурацией. Вот здесь, в истории хранилища, в этом незамысловатом интерфейсе, мы можем сделать любые пометки, который однозначно укажут нам на информацию по доработке: номер заявки в системе учета, ссылка на конкретную заявку, комментарий. Таким образом конкретная доработка будет «увековечена» в системе.

Самый внимательный мог заметить стрелку от продуктивной системы к папке обмена конфигурациями. Она, как понимаете, там не просто так 😊. Это та маленькая возможность, которой, к сожалению, не пользовались мои разработчики, и из-за чего я был вынужден тратить много времени на перенос доработок в свою тестовую систему. А стрелка эта, всего лишь, означает возможность выгрузить продуктивную конфигурацию и применить её в любом окружении. В хранилище у моих разработчиков было сделано много изменений от разных разработчиков (в том числе и тех, кто уже давно не занимается нашей конфигурацией), и многие изменения уже были не актуальны. Но команда разработчиков упорно несла этот «груз» разработки сквозь времена, хотя можно было так же зафиксировать это в своем хранилище и при необходимости достать нужный код. Хотя я сомневаюсь, что кому-то может понадобиться чужой старый код по доработке, которая уже никому не нужна 😊 А еще эта функция нужна, когда в компании есть несколько тестировщиков, работающих над разными доработками  — в этом случае один ответственный за перенос доработок должен уведомлять тестировщиков обо всех изменениях продуктивной конфигурации и выгружать им актуальную версию конфигурации продуктива.

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