Как организовать разработку 1с

Обновлено: 06.01.2025

Привет, Хабр!
В этой статье мы расскажем, как построен процесс разработки платформы «1С:Предприятие», как мы работаем над обеспечением качества, и поделимся уроками, которые получили, создавая один из самых больших российских программных комплексов.

Люди и процессы

Средства разработки (Конфигуратор)
Веб-клиент
Серверная инфраструктура и отказоустойчивый кластер
и т.д.

С другой стороны, в практиках, которые направлены «вовнутрь», команды достаточно автономны. Например, инспекции кода сейчас применяются во всех командах (и существуют общие правила, определяющие обязательность прохождения ревью), но были внедрены в разное время и процесс построен по разным правилам.
То же самое касается организации процесса — кто-то практикует варианты Agile, кто-то использует другие стили ведения проекта. Канонического SCRUM, кажется, нет нигде — специфика коробочного продукта накладывает свои ограничения. Например, замечательная практика демонстрации оказывается неприменимой в неизменном виде. Другие практики, например, роль Product Owner, имеют у нас свои аналоги. В качестве Product Owner по своему направлению обычно выступает руководитель группы. Помимо технического лидерства в команде, одной из самых главных его задач является определение дальнейших направлений развития. Процессы выработки стратегии и тактики развития платформы – это сложная и интересная тема, которой мы посвятим отдельную статью.

Работа над задачами

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

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

Анализ проблемы и вариантов решения
Описание выбранного решения
Описания технических деталей реализации

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

Уроки и рецепты

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

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

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

Тесты

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

Unit-тесты

На C++ мы пишем unit-тесты. Как уже упоминалось в предыдущей статье, мы используем модифицированные варианты Google Test и Google Mock. Например, типичный тест, проверяющий экранирование символа амперсанда ("&") при записи JSON, может выглядеть так:

Интеграционные тесты

Следующий уровень тестирования — интеграционные тесты, написанные на языке «1С:Предприятие». Именно они образуют основную часть наших тестов. Типичный набор тестов представляет собой отдельную информационную базу, хранящуюся в *.dt файле. Инфраструктура тестов загружает эту базу и вызывает в ней заранее известный метод, который вызывает уже отдельные тесты, написанные разработчиками, и форматирует их результаты так, чтобы их могла интерпретировать инфраструктура CI (Continuous Integration).

В данном случае, если результат записи разойдётся с эталоном, вылетит исключение, которое инфраструктура перехватит и интерпретирует как провал теста.

Наша система CI сама выполняет эти тесты под различные версии ОС и СУБД, включая 32- и 64-разрядные Windows и Linux, а из СУБД — MS SQL Server, Oracle, PostgreSQL, IBM DB2, а также нашу собственную файловую базу.

Пользовательские тестовые системы

Третий и самый громоздкий вид тестов — это т.н. «Пользовательские тестовые системы». Они применяются тогда, когда проверяемый сценарий выходит за пределы одной базы на 1С, например, при тестировании взаимодействия с внешними системами через веб-сервисы. Для каждой группы тестов выделяется одна или несколько виртуальных машин, на каждую из которых устанавливается специальная программа-агент. В остальном разработчик теста имеет полную свободу, ограниченную только требованием выдавать результат в виде файла в формате Google Test, который может быть прочитан CI.

Упомянутые выше тесты пишут сами разработчики платформы, на С++ или создавая небольшие конфигурации (прикладные решения), заточенные под тестирование конкретного функционала. Это является необходимым условием отсутствия ошибок, но не достаточным, особенно в такой системе как платформа 1С: Предприятие, где большая часть возможностей не являются прикладными (используемыми пользователем напрямую), а служат основой для построения прикладных программ. Поэтому существует ещё один эшелон тестирования: автоматизированные и ручные сценарные тесты на реальных прикладных решениях. К этой же группе можно отнести и нагрузочные тесты. Это интересная и большая тема, про которую мы планируем отдельную статью.

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

Для каждой конфигурации сборки(Windows x86 и x64, Linux x86 и x64) заведены свои задачи по сборке, которые запускаются параллельно на разных машинах. Сборка одной конфигурации занимает длительное время — даже на мощном оборудовании компиляция и линковка больших объёмов C++ представляет непростую задачу. Кроме того, создание пакетов под Linux (deb и rpm), как оказалось, занимает сопоставимое с компиляцией время.
Поэтому в течение дня работает «укороченная сборка», которая проверяет компилируемость под Windows x86 и Linux x64 и выполняет минимальный набор тестов, а каждую ночь работает регулярная сборка, собирающая все конфигурации и прогоняющая все тесты. Каждая собранная и проверенная ночная сборка помечается тэгом — так, чтобы разработчик, создавая ветку для задачи или вливая изменения из основной ветки, был уверен, что работает с компилирующейся и работоспособной копией. Сейчас мы работаем над тем, чтобы регулярная сборка запускалась чаще и включала больше тестов. Конечная цель этой работы — обнаружение ошибки тестами (если её можно обнаружить тестами) в течение не более двух часов после коммита, чтобы найденная ошибка была исправлена до конца рабочего дня. Такое время реакции резко повышает эффективность: во-первых, самому разработчику не нужно восстанавливать контекст, с которым он работал во время привнесения ошибки, во-вторых, меньше вероятность, что ошибка заблокирует чью-нибудь ещё работу.

Статический и динамический анализ
- CppCheck
- PVS-Studio
- Встроенный в Microsoft Visual Studio
- обращений к неинициализированной памяти
- обращений к освобождённой памяти
- выходов за границы массива и т.д.
Организационные меры обеспечения качества

Помимо автоматических проверок, выполняемых машинами, мы стараемся встраивать обеспечение качества в ежедневный процесс разработки.
Наиболее широко применяемая практика для этого — peer code review. Как показывает наш опыт, постоянные инспекции кода не столько отлавливают конкретные ошибки (хотя и это периодически происходит), сколько предотвращают их появление за счёт обеспечения более читаемого и хорошо организованного кода, т.е. обеспечивают качество «в долгую».
Другие цели преследует ручная проверка работы друг друга программистами внутри группы — оказывается, даже поверхностное тестирование не погруженным в задачу человеком помогает выявить ошибки на раннем этапе, ещё до того, как задача влита в ствол.

Eat your own dogfood

Но самым эффективным из всех организационных мер оказывается подход, который в Microsoft называется «eat your own dogfood», при котором разработчики продукта оказываются первыми его пользователями. В нашем случае «продуктом» оказывается наш таск-трекер (упомянутая выше «База задач»), с которой разработчик работает в течение дня. Каждый день эта конфигурация переводится на последнюю собранную на CI версию платформы, и все недочеты и недостатки сразу сказываются на их авторах.
Хочется подчеркнуть, что «База задач» — серьёзная информационная система, хранящая информацию о десятках тысяч задач и ошибок, а число пользователей превышает сотню. Это не сравнимо с самыми крупными внедрениями 1С: Предприятия, но вполне сопоставимо с фирмой среднего размера. Конечно, не все механизмы можно проверить таким способом (например, никак не задействована бухгалтерская подсистема), но для того, чтобы увеличить покрытие проверяемого функционала, есть договоренность, что разные группы разработчиков используют разные способы подключения, например, кто-то использует Web-клиент, кто-то тонкий клиент на Windows, а кто-то на Linux. Кроме того, используется несколько экземпляров сервера базы задач, работающие в разных конфигурациях (разные версии, разные ОС и т.д.), которые синхронизируются между собой, используя входящие в платформу механизмы.
Помимо Базы задач есть и другие «подопытные» базы, но менее функциональные и менее нагруженные.

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

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

Особенности разработки
1. «Объекты УП, УТ, КА» — объекты, входящие во все прикладные решения: Управление Торговлей, Комплексная Автоматизация, Управление Предприятием (русскоязычное название ERP).
2. «Объекты УП, КА» — объекты, относящиеся только к конфигурациям Комплексная Автоматизация и ERP.
3. «Объекты УП» — объекты, относящиеся только к решению ERP
Цифры после запятой

Версия продукта ERP состоит из четырех чисел, разделенных точками. Например — 2.1.3.117.
- Первое число (редакция) в версии меняется крайне редко (например КА 1.х.х.х и КА 2.х.х.х разделяет почти 8 лет).
- Второе число (подредакция) меняется примерно раз в год. В версии с новой подредакцией выпускается новая функциональность. Выпуск таких версий часто приурочивается к началу календарного года, чтобы у пользователей было достаточно времени на «переезд» на новую версию.
- В версиях с новым третьим числом (релиз) развивается существующая функциональность; новый релиз выходит примерно раз в два-три месяца.
- Версии с обновленным четвертым числом (исправительные сборки) содержат в себе только исправления ошибок и обновления для соответствия текущему законодательству. Выходят каждые две недели.
1. 2.1.3.X – Поддерживаемый релиз предыдущей подредакции. Будет выпускаться до конца 2016 года. В этой версии идет только исправление ошибок и правки для соответствия текущему законодательству.
2. 2.2.1.X – Текущий релиз текущей подредакции. В нем новая функциональность подредакции. Для него до выпуска релиза 2.2.2.X, будут выпускаться исправительные сборки.
3. 2.2.2.X – Развитие функциональности текущей подредакции. Именно этот релиз активно разрабатывается.
Учитывая, что из каждой ветки ERP получаются, помимо ERP, еще 3 решения – КА, УТ и УТ Базовая – получаем 12 версий продуктов, находящихся в 12-ти разных хранилищах.
В ходе разработки мы имеем до 4 горизонтов планирования, например:
1. 2.1.3 (поддерживается), решаем, какие ошибки правятся, какие проекты, связанные с изменением законодательства, будем реализовывать. Будут реализованы только те изменения, которые вступят в силу в 2016 году. Горизонт – до конца 2016 г.
2. 2.2.1 (поддерживается) – исправляются «внешние» ошибки + изменения законодательства, вступающие в силу до выхода 2.2.2. Горизонт – до выхода 2.2.2.
3. 2.2.2 (активно разрабатывается) — исправляются «внешние» ошибки + найденные нами ошибки + реализуется новая функциональность. Горизонт – до выхода 2.2.3
4. 2.2.3 (планируется). Если проект большой, то он может сразу разрабатываться на эту версию (и не войдёт в предыдущую). Горизонт – до выхода 2.2.4 или до конца 2017 года.
Использование продукта «1С:Система проектирования прикладных решений» в разработке ERP
1. Запрос от партнера или клиента. Такие запросы мы собираем, в частности, на партнерских семинарах; путем голосования среди партнеров мы выделяем наиболее приоритетные из них.
2. Запрос может возникнуть в ходе пилотного проекта по внедрению новой версии в том случае, если у клиента возникло важное для него пожелание.
3. Запрос от нашей службы техподдержки (точнее, запрос от партнера или клиента, прошедший через нашу техподдержку), запрос с нашего партнерского форума или от нашего аккаунт-менеджера (который сопровождает важного для нас клиента/клиентов).
4. Запрос от команды разработки платформы 1С:Предприятие. Платформенная команда просит команду разработки ERP (и других типовых конфигураций) использовать новую платформенную функциональность – например, интерфейс Такси, отказ от модальных окон, отказ синхронных вызовов и т.д.
5. Рефакторинг, оптимизация архитектуры, улучшение юзабилити.
Поводом для рефакторинга (п.5) могут быть серьезные архитектурные изменения (например, пересмотр распоряжений на отгрузку, когда вместо накладных стали использоваться заказы).

Продукт СППР поставляется в составе ERP (но его можно купить и отдельно). Решение ERP может быть запущено в режиме интеграции с СППР; в этом случае на каждой форме будет кнопка «Открыть функциональную модель», при ее нажатии откроется описание функциональности формы в СППР.

Вот, что открывается – это модель рабочего места в IDEF0:

Можно и наоборот – изучать функциональную модель и из нее открывать формы рабочих мест. Такой режим можно использовать при изучении работы программы.
Важный момент – открывается не СППР, открывается форма внутри ERP, куда подгружаются данные из СППР. Т.е. интеграция «бесшовная» (пользователь ее не видит). Этот прием применяется при интеграции и с другими продуктами. Например, с 1С:Документооборот (можно работать не выходя из ERP с почтой, задачами, бизнес-процессами, которые работают в другой базе).

Как мы разрабатываем ERP: 6 контрольных точек проекта
- Качественное проектирование, учет всевозможных сценариев, сопряжение со смежными блоками
- Сроки
- Качество архитектуры, пользовательского интерфейса
- Написание справки, оформление проекта, в т.ч. разработку функциональной модели
Точка 1. Открытие проекта

Тим-лид заводит технические проекты в СППР списком на релиз. В каждом проекте расписываются цели, указываются реализуемые требования. Список перед началом работы над релизом обсуждается с руководителем разработки. Собственно при открытии проекта совещаний не проводят – просто проект в СППР посылают на открытие.
Команда проекта приступает к разработке концепции.

Точка 2. Согласование концепции

Для согласования концепции проводится онлайн или офлайн встреча, в которой участвуют ответственный за проект, тим-лид, руководитель разработки, вовлеченные в проект специалисты. Обычно к этому этапу у ответственного за проект готов «крупноблочный» концепт, который дошлифовывается в ходе встречи. Также обсуждаются (и прописываются в СППР) сценарии, описание пользовательского интерфейса. Если требование родилось из запроса партнеров или клиентов, то материалы проекта (концепции, сценарии, UI) могут быть отправлены партнеру/клиенту для оценки решения.
В процессе встречи согласуется трудоемкость создания прототипа (обычно создание прототипа занимает до 5 рабочих дней). Команда приступает к созданию прототипа.

Точка 3. Согласование прототипов
- Согласование правильности описания проекта в СППР (в частности, отслеживается, что все задачи на предыдущих контрольных точках проекта выполнены).
- Какие новые объекты метаданных (справочники, документы и т.д.) будут добавляться в решение
- Какие изменения будут делаться в уже существующих объектах метаданных
- Согласование планов обменов данными с другими решениями(будут ли новые/измененные данные участвовать в обмене данными с другими приложениями, и если да – то как именно)
Точка 4. Согласование разработанного решения

Решение разработано, подготовлена презентация (в формате PowerPoint). Часто проводится очное совещание с «живым» показом разработанного решения.
Если проект публичный (опубликован в доступном партнерам списке планов на сайте 1С), то презентация выкладывается на партнерском форуме в разделе ERP, чтобы все заинтересованные партнеры могли ознакомиться и высказать свои замечания.

Точка 5. Тестирование и аудит проекта

Точка 6. Окончание проекта

Закрываем проект в СППР – присваиваем ему статус «Выполнено».

Выпуск версии

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

Исправительные сборки

Каждые две недели мы выпускаем исправительные сборки к версиям; на сегодня это 2.1.3.x, после выхода релиза 2.2.1 будут выпускаться 2 исправительные сборки — 2.1.3.x и 2.2.1.х. От регистрации ошибки до появления ее в исправительном релизе у нас проходит менее двух недель; наша статистика показывает, что среднее время от обращения клиента с ошибкой в ERP в поддержку до выхода ее исправления в исправительной сборке на сегодня – 9 дней.

Разветвленная разработка

В групповой работе над ERP мы стараемся использовать средства, предоставляемые нам платформой 1С:Предприятие. Конфигурации хранятся в хранилище конфигураций, при чекине новой функциональности в ветки используется стандартный механизм поставки и поддержки. Все операции автоматизируются по максимуму; в случае, если объекты менялись только на стороне разработчика – объединение кода происходит без участия программиста. Если для объединения исходников нужно вмешательство разработчика, обычно мы используем встроенные возможности платформы. Но есть также возможность вызова сторонних инструментов сравнения/объединения из инструментов платформы (например, KDiff3 или Araxis). Кстати, эта фича – вызова сторонних инструментов сравнения/объединения — была добавлена в платформу по запросу именно команды разработки ERP.

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

Естественно, это (захват объекта) может продолжаться достаточно долго, пока не завершится разработка, человек и того хуже, может уйти в отпуск, заболеть и забыть отпустить объект конфигурации, а время идет и задачу нужно решать. Если человек длительно отсутствует на рабочем месте, а объект все же нужен прямо сейчас, то выход один - отменять захват объекта администратором хранилища принудительно. В этом случае разработчик, захвативший объект, потеряет изменения, которые он вносил в объект. Мягко говоря, подход «так себе».
1. Все говорят – все слушают (параллельный подход):
В более опытной команде разработчиков строится несколько иной подход, когда полностью чистая база данных подключается к хранилищу конфигурации и используется только для получения/помещения изменений, такая база используется только в режиме конфигуратора. Есть своим преимущества, более быстрая реструктуризация конфигурации БД в следствие отсутствия данных в таблицах БД, маленький объем самой базы. После получения изменений из хранилища все изменения сохраняется в файл конфигурации и уже сравнением/объединением (или полной загрузкой) конфигурации переносятся в свою тестовую копию базы с реальными данными, в которой как раз и ведется разработка. После завершения разработки конфигурация из тестовой БД снова сохраняется в файл и сравнением/объединением, с захватом объектов все переносится и помещается в основное хранилище конфигурации.

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

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

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

Имеем какую-то конфигурацию (собственную, отраслевую или от фирмы 1С не имеет значения).

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

Содержание общего модуля достаточно банальное

Для этой конфигурации создано хранилище.

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

Разработчик 2 устал постоянно ждать на захваченных объектах, начальник ругает, нужно делать работу, а не сидеть сложа руки. Он сохранил конфигурацию в файл и загрузил в свою тестовую базу. Ведет разработку там и не ждет Разработчика 1 или еще кого-либо. Позже перенесет свои наработки в хранилище пусть и с определёнными рисками.

Разработчик 3 пойдет по пути №2, но при этом не будет заботиться и переживать о контроле, он отдаст это механизмам 1С. Создаёт файл поставки от основного хранилища конфигурации. После чего этот файл поставки загружает в свою тестовую базу, поставив её на поддержку.

Загрузив файл поставки в свою тестовую базу, видит, что все объекты находятся на поддержке или, как говорят, «на замке»:

На этом этапе технология разветвленной разработки (п. 4. Разработка технических проектов) гласит - Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».

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

Открываем настройку поддержки конфигурации

И включаем возможность изменения

Устанавливаем правила поддержки

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

Для примера мы поменяем общий модуль «ОбщийМодульДляВсегоВызовСервера» и «ДокументРазработчика3», добавим свой общий модуль и справочник.

Процедуру, которая имела вид

Мы преобразовали к такому:

В результате чего конфигурация принимает примерно такой вид:

Аналогично поступят Разработчик 1 и Разработчик 2, мы опустим этот момент, скажем лишь то, что Разработчик 1 без особых переживаний сделает это прямиком в хранилище конфигурации с захватом объектов, Разработчик 2 сохранит свой файл конфигурации и перенесет все сравнением/объединением, потратив какое-то количество времени на все это. И наступает наша очередь (мы самые последние) переносить свой проект в хранилище.

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

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

Обновление базы из хранилища:

Видим следующую картину обновления

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

Снимаем отметку в корне конфигурации, тем самым сняв отметки со всех объектов метаданных

И устанавливаем фильтр в режим «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».

В данном режиме возвращаем отметку в корне конфигурации, отметив все объекты в этом режиме

И переключаем фильтр в режим «Показывать только дважды измененные свойства»

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

В данном случае я вношу результирующие изменения, просто добавив их в конкретную процедуру

И на этом все! Если режим «Показывать только дважды измененные свойства» вообще не показал ничего, значит, мест, где пересекалась разработка с другими разработчиками, нет вообще и переживать тем более не о чем!

Устанавливаем правила поддержки для новых объектов, как и ранее, на свое усмотрение:

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

Там (в основном хранилище конфигурации при сравнении/объединении) мы увидим вот такую приятную картину – мы видим только те изменения, которые вносили мы:

Объединяем с хранилищем и понимаем, что мы сократили огромное количество времени и сил.

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

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

UPD 08.06.2021

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

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

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

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

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

Также очень важно, чтобы у нас во всех процессах работы с продуктом использовались единые стандарты, инструменты, единое окружение. Например, чтобы команда эксплуатации использовала те же инструменты, которыми пользуются разработчики – чтобы в обеих командах при развертывании баз 1С использовался rac, ras, еще какие-то инструменты. Чтобы соблюдались единые инструменты разработки – конфигуратор или EDT, и т.д.

И немаловажный момент для DevOps – системы автоматизации сборки и выпуска (CI/CD/Jenkins/GitLab/Azure и т.д.) должны быть доступны соответствующим лицам с правильными ролями. И могли использоваться на разных этапах DevOps.

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

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

На слайде DevOps присутствует первая мантра «Все есть код» – она означает, что все действия, которые мы выполняем при разработке, при эксплуатации продуктов, нужно фиксировать. Это не должны быть действия, которые мы каждый раз интерактивно “закнопываем”. Все рутинные операции, которые выполняет разработчик или эксплуататор, должны выполняться в автоматическом режиме.

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

В своем выступлении я затрону шесть из восьми этапов DevOps. На «знаке бесконечности» они расположены слева и в середине – это:

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

Хранилище конфигурации

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

Для осуществления групповой разработки прикладного решения на общедоступном сетевом ресурсе создается хранилище конфигурации и назначается его администратор:

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

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

Окно хранилища конфигурации

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

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

В любой момент времени можно выполнить сравнение текущей конфигурации с хранилищем или выполнить сохранение хранилища как конфигурации.

История хранилища

Конфигуратор 1С:Предприятия поддерживает ведение истории хранилища:

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

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

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

Отчет по версиям хранилища отражает состав добавленных или измененных объектов:

Отчет по объектам разработки содержит информацию об изменениях, которые были внесены в конкретные объекты прикладного решения:

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

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

Работа с хранилищем в окне конфигурации

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

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

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

Работа с хранилищем без подключения

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

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

Удаленная работа с хранилищем конфигурации

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

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

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

Читайте также: