Групповая разработка конфигурации

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

Сложности при адаптации ПО в холдинге

Практически все пользователи сталкиваются с одинаковыми сложностями при адаптации ПО и изменении конфигурации:

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

Еще одна проблема, с которой придется столкнуться при изменении конфигурации - это необходимость контроля качества готового продукта. Заказчик и его команда не должны заниматься тестированием продукта, им нужно предоставить полностью готовый к работе продукт. Разработчики, в свою очередь, должны выполнить свою работу так, чтобы у заказчика не возникло претензий к качеству разрабатываемого продукта.

Становление командной разработки в компании «1С»

В среде разработчиков выделяется несколько видов групповой разработки

Ручная сборка

Ручной сборкой конфигурации занимаются не только при групповой, но и при любой разработке в «1С». В чем заключается суть ручной сборки? Один или несколько специалистов собирают конфигурацию вручную, далее выполняются какие-то доработки. Затем доработки переносятся в рабочую конфигурацию, либо объединяются с доработками других разработчиков и при помощи файла конфигурации помещаются в рабочую базу. Из преимуществ этого вида групповой разработки можно выделить возможность редактирования объекта, независимо друг от друга, и проведение ревью кода на этапе сборки. Недостатками являются ошибки на этапе сборки и трата большого количества времени на процесс объединения доработок.

В компании «1С» ручная сборка использовалась недолго. Так как колоссальное количество времени тратилось на объединение отдельных разработок и возросло количество ошибок. Нужно было срочно искать альтернативный метод групповой разработки.

Использование различных модификаций хранилища конфигурации и его роль в групповой разработке

Хранилище конфигураций – это файловая ИБ, которая не содержит данных, зато в ней есть структура разрабатываемой конфигурации. Разработчик может вносить изменения и доработки в конфигурацию. Работать с хранилищем могут одновременно несколько разработчиков, пока работает один, для других доступен только режим чтения.

Классическая схема использования хранилища конфигураций изображена на схеме.

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

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

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

Как работала эта схема? В тестовую базу, существующую отдельно от хранилища, загружалась конфигурация из хранилища. Тестировщик проверял ее на наличие ошибок и, если находил их, отправлял на доработку. Разработчик вносил изменения и в хранилище разработки, и в тестовой базе.

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

И опять нужно было искать новую, более эффективную схему.

Цикл разработки ПО: взаимодействие специалистов разных сфер деятельности

После использования разных схем групповой разработки в компании «1С» пришли к следующей схеме

На первый план в налаженной схеме выдвинули принцип взаимодействия между членами команды, ведь технический процесс отражает, как налажен этот процесс в команде.

•  В течение недели (именно столько отводится разработчикам) выполняется доработка ПО по техзаданиям, согласованным с заказчиком.
•  После выполнения разработки программист в своей конфигурации согласовывает с заказчиком изменения, не помещая их при этом в хранилище. Заказчик оценивает результаты работы и вносит свои предложения и замечания, если они есть.
•  Разработчик вносит в конфигурацию изменения и отправляет ее на тестирование.
•  Одновременно с этим процессом идет процесс технического документирования, которым занимается технический писатель.
•  В то же время разработчик и тестировщик сообща работают над релизом, который им отправили на доработку. Они выявляют, исправляют ошибки и тестируют полученный результат.
•  Если готовый релиз работает правильно и успешно прошел тестирование, он помещается в рабочую конфигурацию

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

Использование нескольких хранилищ: преимущества и недостатки

После работы по представленным выше схемам групповой разработки в компании «1С» была найдена та, по которой специалисты работают и сейчас. Именно она позволяет выполнить все поставленные задачи.

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

• Каждый тестировщик работает в отдельной базе со своей информацией, то есть никто не мешает друг другу, а значит – работа ведется быстрее и с минимумом ошибок в итоге.
•  Не нужно ждать, пока освоботиться конфигуратор. Чтобы отправить изменения на тестирование, достаточно поместить их в тестовое хранилище.
•  Контроль истории изменений в тестовом хранилище – полезная функция при групповой разработеке.
•  «Тестовый контур» - новая функция, о которой будет рассказано чуть позже.

Третье хранилище используется для хранения рабочей информационной базы. Оно предназначено не для разработки, а для контроля истории изменений, которые были внесены в рабочую базу. В случае каких-либо неприятных инцидентов с конфигурацией это хранилище позволяет выявить, на каком этапе разработки произошла ошибка, ведь в него вносится вся информация о внесенных в рабочую базу изменениях.

Согласно графику, составленному разработчиками заранее, протестированные изменения переносятся в рабочие базы, а готовая разработка передается на тестирование.

Как ведется работа по исправлению выявленных ошибок?

Обнаруженные при тестировании ошибки исправляются разработчиками в двух хранилищах – хранилище разработки и хранилище тестирования. Тестировщик тестирует свою задачу уже с внесенными изменениями, а разработчик продолжает работать независимо.

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

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

Теперь обратимся к плюсам и минусам такой схемы групповой разработки.

Начнем с достоинств:

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

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

Тестовый контур информационных баз

Тестовый контур – это имитация среды, на которой ведутся работы. Тестовый контур развернут на таких же серверах, что и реальные рабочие базы, в нем используются те же службы, операционные системы и даже базы 1С. Всё это – копии реальных рабочих баз, которые время от времени обновляются.

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

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

Смотрим в будущее: какие технологии и инструменты можно использовать для улучшения групповой разработки

Как видим, в компании «1С» используются лучшие технологии для повышения качества разработанных продуктов и улучшения работы специалистов.

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

Тестирование, доработка, исправление ошибок при интенсивном использовании ПО в крупной компании

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

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

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

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