Групповая разработка конфигураций в крупном холдинге

Трудности, с которым сталкивается бизнес в процессе адаптации ПО под себя

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

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

История становления командной разработки в нашей компании. Как мы жили, когда были маленькие, и с чем сталкивались в процессе роста?

Какие виды групповой разработки могут быть, через что прошли мы.

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

Когда пять лет назад я пришел в компанию, не было департамента ИТ, был только небольшой ИТ-отдел из 5 человек. Это был просто отдел разработки. Никакого хранилища тогда не было, конфигурации собирались вручную – один или два разработчика конфигурационных единиц выполняли какие-то доработки, и вносили в конфигурацию новую функциональность. Потом либо эти доработки переносились в рабочую конфигурацию, либо изменения различных специалистов сверялись и объединялись, и уже результат объединения с помощью файла конфигурации натягивался на рабочую базу. Всё вручную!

Конечно же, у такого подхода были существенные недостатки:

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

Но у такого подхода есть и свои преимущества.

• Это, во-первых, возможность редактирования одного объекта конфигурации одновременно несколькими разработчиками (то, чего мы лишены при использовании хранилища).
• И это – возможность проведения рефакторинга, ревью кода, его инспекции на этапе сборки результата разработки самим архитектором.

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

Роль хранилища конфигурации 1С в групповой разработке. Его плюсы и минусы.

Я думаю, не стоит повторяться и подробно объяснять, что такое хранилище – это и так все знают. Хранилище – это полезный инструмент для групповой разработки от фирмы 1С.

Схема использования хранилища выглядит примерно так, как показано на слайде. Это – классический подход, когда:

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

Но и эта схема просуществовала недолго. Потому что очень быстро выявились ее существенные недостатки.

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

Поэтому следующим шагом было решено вынести тестовую базу из цикла разработки.

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

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

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

Долго так продолжаться не могло, поэтому было принято решение что-то поменять.

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

Итак, преимущества:

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

Ну и недостатки, с которыми мы столкнулись:

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

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

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

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

Что если использовать несколько хранилищ? Как это помогает и вредит?

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

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

Немного слов о том, как решаются различные коллизионные ситуации.

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

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

Какие очевидные недостатки есть у этой схемы:

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

В чем плюсы такой организации работы?

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

А если говорить про недостатки:

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

Организация тестового контура информационных баз для тестировщика и заказчика.

Вернемся к тому «Тестовому контуру», который у нас подключен к тестовому хранилищу наряду с базами тестировщиков. Что это такое?

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

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

Каковы цели организации тестового контура?

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

Дальнейшие планы по улучшению качества продукта. Какие еще инструменты и технологии можно задействовать?

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

• Во-первых, мы планируем внедрение системы контроля версий;
• А еще, спасибо фирме 1С, мы собираемся использовать в разработке новый полезный механизм расширений конфигурации. Он особенно интересен после выхода платформы 8.3.9, когда в расширениях нам стало доступно изменение уже абсолютно любых модулей. Использование этого механизма нам видится очень перспективным, потому что оно хорошо подходит к специфике организации нашего бизнеса.

Как происходит тестирование, исправление ошибок, разработка внешних отчетов/обработок и правил обмена в крупной компании при интенсивном использовании ПО?

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

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

Желаю всем качественного результата и довольного заказчика!

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.