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

Программирование - Теория программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

***************

Данная статья написана на основе доклада, представленного автором на конференции Infostart в 2016 году. Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

См. также

Комментарии
1. Виталий Попов (Сурикат) 168 15.08.17 14:53 Сейчас в теме
А у нас следующая схема:

1. Разработчик выполняет разработку в собственной базе (с хранилищем или без на его усмотрение)
2. Когда разработка завершена, то доработки переносятся в тестовое хранилище
3. Тестируем, исправляем
4. Переносим в хранилище рабочей базы

Так сделали для того, чтобы убрать необходимость синхронизации окончания разработки к определенным срокам. Да и каждый разработчик работает над независимым ТЗ.
2. Иван Пимуков (Irwin) 284 15.08.17 15:19 Сейчас в теме
Все в том или ином виде приходят к технологии разветвленной разработки конфигураций: https://its.1c.ru/db/v8std#content:2149184358:hdoc
tenikov; Stepa86; +2 Ответить
3. PerlAmutor IC (PerlAmutor) 26 15.08.17 15:59 Сейчас в теме
А у нас 1 хранилище и мы занимаемся всем сразу, от обучения пользователей и заканчивая администрированием сервера. Программисты принимают телефонные звонки, ходят на совещания, подключают сканеры штрих-кодов к рабочим местам (ставят драйвера в систему, лазят под стол), настраивают права в системе. Работают сверхурочно без оплаты. По выходным. И из дома и отпуска.
Их ненавидят все пользователи за то, что база тормозит, из неё постоянно выгоняют пользователей, она часто глючит.
Работают вопреки, из-за принципа и желания наконец сломать прогнившую систему.
Deslime; LeXXuS_ju; Zhilyakovdr; comol; Brawler; Hartge; srvrv; Solovyeff; dbimah; Waanneek; Sirin; Sla; +12 Ответить
7. Леопольд Роскошный (ЛеваРоскошный) 32 16.08.17 13:40 Сейчас в теме
(3) Run forrest Run.

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

ничему не научишься и чудовищно отстанешь от своих коллег.
Brawler; CyberCerber; kredko; Irwin; +4 Ответить
4. Илья Шу (solary) 136 16.08.17 09:59 Сейчас в теме
Разрабатываете ли внешние обработки/отчеты? Как следите, чтобы разработчики одновременно не работали над одной обработкой? Используете SVN или еще что-нибудь?
Интересуюсь, потому что сейчас столкнулись с этой проблемой и пока только ищем удобное решение, чтобы можно было как минимум заблокировать обработку для изменений другими.
5. Дмитрий Макаров (Fejerverk) 16.08.17 10:05 Сейчас в теме
(4) У нас решили это немного "топорным" способом - внешние обработки выкладываются в конфигурацию и захватываются. Если захвачено - значит в работе у того кто взял, а он может уже обновлять как внешнюю не отпуская в конфигурации хоть 10 раз.
9. Станислав Ганиев (benony) 265 16.08.17 13:55 Сейчас в теме
(4)На момент доклада мучились как попало, но на сегодняшний день перешли на Git, в репозитории у нас версионируются все внешние файлы: правила обмена, внешние отчеты и обработки, расширения, автотесты и т.д.
CyberCerber; MGraf; +2 Ответить
11. Илья Шу (solary) 136 17.08.17 08:32 Сейчас в теме
(9)Разве в Git можно захватить и заблокировать для других обработку? Нам важно, чтобы другой разработчик не взялся изменять обработку, пока этим занимается первый.
12. Егор Иванов (Infactum) 240 17.08.17 10:23 Сейчас в теме
(11) Странный подход.
При групповой разработке как раз нормальная ситуация, что несколько человек работают с одним "объектом", но над разными задачами. Потом в процессе слияния разрешаются конфликты, если они возникнут.
Просто нужно понимать, что организационная часть тоже не последнее место занимает, и не надо поручать одному разработчику, допустим, тотальный рефакторинг обработки, а другому при этом косвенно связанную с этой обработкой задачу.
13. Станислав Ганиев (benony) 265 17.08.17 10:43 Сейчас в теме
(11)
(12) Только дополню Егора. При работе с Гитом договариваемся, что все изменения каждый программист коммитит в отдельной фиче, и ни в коем случае не в develop! Потом при принятии пул-реквестов мастер по код-ревью сверяет изменения. Поддерживаю Егора - нормальная ситуация. Хотя, лично мне не понятно, что это может быть за супер-обработка, на которую наваливается толпа кодеров ))) Встройте ее в конфу, раз так критично.
14. Илья Шу (solary) 136 17.08.17 14:24 Сейчас в теме
(13) Обычно случается, что первый вносит новый функционал в обработку, а в это время находится какой-нибудь баг и второй разработчик правит его. После этого первый разработчик помещает обработку на сервер и затирает код второго. Согласен, что необходимо сравнивать обработки, тогда этого не случится.
6. Александр Никитин (ManyakRus) 273 16.08.17 12:22 Сейчас в теме
1) непонятно сколько у вас программистов работают над одной конфигурацией,
если до 5 то не надо огород городить :) обычное одно хранилище подходит
2) Если много конфигураций - ещё лучше, на каждую назначить своего ответственного программиста - тогда тоже 1 хранилище надо
3) Все эти супер схемы с тремя хранилищами нужны только из-за безответственности когда никто ни за что не отвечает, делают 1 мелкое задание - сделал и забыл, а должно быть у каждого своя зона ответственности по базам и др.
CyberCerber; sheffchik; Yakud3a; zqzq; Anton64; +5 Ответить
10. Станислав Ганиев (benony) 265 16.08.17 14:08 Сейчас в теме
(6)
(7)
(8)
У нас над каждой конфигурацией работает от 2 до 10 программистов в ответственной группе. Но частенько туда вносят доработки коллеги из других групп.Лично у меня сейчас под мою ответственность три конфигурации, и на каждой своя схема: 1. Описанная в статье с тремя хранилищами; 2. Та, о которой говорит Илья (8); 3) И типовая на 8.3 исключительно на расширениях с использованием Git. Сравниваю, что называется, на собственной шкуре :)). Согласен, что первая получилась громоздкая, другие две показывают себя с лучшей стороны: геморроя меньше, контроль тот же (где-то даже лучше). Плюс начали использовать автотесты - те ваще жизнь упрощают ))) А дальше поживём - увидим...
8. Илья Васильев (swimdog) 560 16.08.17 13:54 Сейчас в теме
Сколько программистов? У нас работало до 10 с 1 хранилищем и полноценным тестированием. У каждого программиста своя база, в которой выполняется разработка и в ней же осуществляется тестирование. После тестирования изменения выкладываются в хранилище. Там их проверяется ответственный на общие ошибки. И оттуда уже попадают в рабочую базу.
Возможно, это не сработает, если есть автоматическое тестирование в отдельной базе.
15. Dimka Andrus (andrusevich) 01.10.17 00:30 Сейчас в теме
На своей шкуре проверено полюбе без теста никуда, в предложеной схеме идет полюбе база тестов. И по принципу у нас обновления в четверг что бы в пятницу можно біыо біы исправить и гулять віходные (7 баз с одинаковой нетиповки самая большая 86гб каскоко помню занимаемся FMGC болуу 3к документов в сутки).
Оставьте свое сообщение