В каком режиме осуществляется разработка конфигурации в 1с
Технология разветвленной разработки конфигураций
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
Методическая рекомендация (полезный совет)
Цели внедрения технологии:
- Повышение качества разрабатываемой конфигурации
- Повышение культуры разработки и тестирования
- Обеспечение непрерывного развития конфигураций в условиях жестких сроков разработки
1. Определения
Плановая версия конфигурации – версия, содержащая существенное развитие функционала, срок выпуска которой назначается заранее.
Исправительная версия – версия, которая выпускается при необходимости срочной публикации исправлений критичных ошибок. В исключительных случаях исправительная версия может содержать какой-то новый функционал (например, доработки, связанные с поддержкой изменения законодательства). Срок выпуска определяется при анализе количества и критичности обнаруженных ошибок плановой версии.
Технический проект – задание на доработку конфигурации. Каждый технический проект имеет четко сформулированную цель и конечный список изменений, которые нужно выполнить, чтобы достигнуть этой цели.
Для организации работ по разработке и сопровождению конфигураций (в т.ч. ведению информации о технических проектах и списка ошибок) рекомендутся использовать Систему проектирования прикладных решений (СППР) .
2. Разработка исправительных версий
2.1. Для выпуска каждой исправительной версии создается новое хранилище на основе конфигурации последней выпущенной версии.
Важно – нужно создавать новое хранилище, а не копировать основное!
2.2. В исправительной версии не должно быть объемных доработок конфигурации, в противном случае нужно пересматривать сроки выпуска плановой версии.
2.3. Все закладки в хранилище исправительной версии должны содержать комментарий.
Требования к содержанию комментариев аналогичны требованиям к закладкам в хранилище плановой версии (см. п.3.4).
2.4. Все изменения, которые выполняются в исправительном релизе, должны синхронно повторяться в основном хранилище. Если в исправительном релизе добавляются новые объекты (реквизиты объектов), то переносить изменения нужно исключительно с помощью сравнения/объединения конфигураций, для того чтобы не различались внутренние идентификаторы объектов конфигурации.
2.5. При сборке исправительной версии рекомендуется устанавливать метку с информацией о номере сборки на закладке той версии хранилища, конфигурация которой идет в сборку. Обычно это последняя на момент сборки закладка.
3. Разработка плановой версии
3.1. Разработка плановых версий ведется в основном хранилище конфигурации.
3.2. Закладки в основное хранилище должны осуществляться таким образом, чтобы каждая закладка переводила конфигурацию хранилища из одного рабочего (готового к выпуску) состояния в другое.
Не допускается закладка не полностью отлаженного функционала! Основное хранилище всегда должно находиться в «неразваленном» состоянии, чтобы в любой момент можно быть начать сборку плановой версии.
3.3. В основном хранилище разрешается выполнять следующие работы:
- исправление ошибок, не требующих перепроектирования, объемного кодирования и тестирования. Если ошибка требует больших переработок и/или пересмотра проектных решений, то исправление такой ошибки должно вестись в рамках технического проекта. Порядок работы с основным хранилищем должен быть таким же, как и по другим техническим проектам;
- встраивание новых версий библиотек;
- встраивание полностью отлаженных, прошедших отладочное тестирование проектов;
- в исключительных случаях в основном хранилище может вестись разработка некоторых проектов, (например, проектов по массовому рефакторингу).
Рекомендуется использовать реализованные в СППР возможности автоматической генерации текстов комментариев для закладок, связанных с исправлением ошибок и встраиванием технических проектов.
3.4. Все закладки в основное хранилище должны содержать комментарий.
Содержание комментария зависит от характера выполненных работ:
- при исправлении ошибки обязательно должен быть указан номер и краткое наименование ошибки в системе баг-трекинга;
- при встраивании новой версии библиотеки должно быть указано название библиотеки и точный номер версии библиотеки;
- при встраивании технических проектов – номер проекта в системе ведения проектной документации, а также краткое наименование;
- при выполнении работ по техническому проекту в основном хранилище комментарий, помимо номера и краткого наименования проекта, должен содержать краткое описание сделанных в этой закладке изменений.
3.5. Все изменения по техническому проекту должны переноситься в основное хранилище за одну закладку. Если необходимо переносить изменения несколько раз, то нужно открывать несколько проектов.
3.6. После переноса изменений в основном хранилище можно исправлять ошибки, наведенные техническим проектом. Для пересмотра проектных решений нужно открывать новый проект.
3.7. При сборке плановой версии рекомендуется устанавливать метку с информацией о номере сборки на закладке той версии хранилища, конфигурация которой идет в сборку. Обычно это последняя на момент сборки закладка.
4. Разработка технических проектов
4.1. Разработка каждого технического проекта ведется в отдельном хранилище.
При использовании СППР хранилище технического проекта может быть созданно автоматически. Если СППР не используется, хранилище технического проекта нужно будет создавать вручную, в соотвествии с порядком, описанном в Приложении 1.
4.2. При постановке хранилища технического проекта на поддержку от основного хранилища, платформа для всех объектов устанавливает правило «Объект поставщика, не редактируется». Для работы над техническим проектом нужно изменить это правило на «Объект поставщика редактируется с сохранением поддержки».
Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».
Для изменения правил поддержки нужно захватить только корень конфигурации, захватывать сами объекты не нужно.
Выполнение этих рекомендаций позволит упростить процесс переноса изменений между основным хранилищем и хранилищем тех. проекта.
4.3. Ответственный за технический проект может периодически обновлять конфигурацию хранилища проекта. Периодичность обновления разработчик определяет самостоятельно.
На частоту обновления могут влиять следующие факторы:
- затрагивает ли технический проект объекты других ответственных;
- проводится ли в данное время рефакторинг общих механизмов;
- ведется ли сейчас в основном хранилище массовое исправление ошибок.
Порядок обновления хранилища технического проекта описан в приложении 2.
4.4. После окончания разработки ответственный согласует сроки завершения отладочного тестирования и сроки внесения технического проекта в основное хранилище. Проекты, затрагивающие большое количество объектов рекомендуется вноситься в основное хранилище ближе к сроку окончания разработки, чтобы уменьшить влияние на другие проекты.
Ответственные за другие технические проекты могут попросить перенести сроки внесения в основное хранилище.
В СППР согласовывать сроки встраивания технических проектов можно, используя функциональность контрольных точек по техническому проекту.
4.5. Внесение проекта в основное хранилище должно осуществляться после завершения отладочного тестирования. Рекомендуется по окончании исправления ошибок, выявленных отладочным тестированием технического проекта, сформировать файл сравнения конфигурации проекта и конфигурации основного хранилища.
4.6. Внесение наработок технического проекта в основное хранилище не должно проводить к длительному захвату объектов основного хранилища. Это достигается тем, что сначала хранилище технического проекта обновляется до состояния основного хранилища (по методике, описанной в приложении 2). Если изменений много, то такое обновление может занять достаточно много времени (до нескольких дней) – за это время конфигурация основного хранилища может измениться. Поэтому процесс обновления может быть итеративным – на каждой итерации обновления отличия в конфигурациях будут становиться все ближе к величине изменений, внесенных техническим проектом.
После каждой итерации обновления целесообразно проводить быструю проверку работоспособности функционала, разрабатываемого в рамках проекта.
Начинать перенос изменений в основное хранилище (захватывать объекты в основном хранилище) следует только тогда, когда конфигурация технического проекта будет отличаться от конфигурации основного хранилища практически только на изменения, вносимые проектом.
4.7. Ответственный за технический проект должен внимательно относиться к внесению изменений в основное хранилище. Нужно помнить, что основное хранилище должно в любой момент времени находиться в состоянии готовности к выпуску плановой версии.
После внесения изменений в основное хранилище разработчики технического проекта совместно с тестировщиками проводят быструю проверку того, что изменения перенесены корректно и не повлияли на работоспособность смежного функционала. Объем проверок и порядок их проведения определяет ответственный за проект.
4.8. После проверки переноса изменений и до закладки изменений в основное хранилище, ответственный обязательно должен запустить проверку конфигурации. Проверку нужно проводить с максимальными настройками.
Закладка изменений в основное хранилище допускается только после того, как будут исправлены все ошибки, выявленные проверкой конфигурацией, которые были привнесены проектом.
4.9. После переноса изменений в основное хранилище ответственный за технический проект удаляет хранилище проекта
5. Нумерация сборок
Изменение номеров версий регламентируется стандартом Нумерация редакций и версий
Здесь будут уточнены правила изменения номера сборки (четвертое число в номере версии)
5.1. Номер сборки следует увеличивать как в основном хранилище, так и в хранилище исправительного релиза в двух случаях:
непосредственно перед сборкой релиза. Это необходимо, чтобы полный номер собранного релиза гарантированно отличался от полного номера предыдущего релиза; при закладке в хранилище обработчика обновления информационной базы. Это необходимо, чтобы после обновления из хранилища у всех участников разработки добавленный обработчик обновления запускался автоматически (только для конфигураций, основанных на Библиотеке Стандартных Подсистем ).5.2.1. При добавлении в хранилище обработчиков обновления информационной базы рекомендуется в рамках этой же закладки повышать номер сборки. Существует два возможных сценария:
Обработчик обновления добавляется при разработке технического проекта в хранилище технического проекта. В этом случае при переносе изменений в основное хранилище следует увеличить номер сборки основного хранилища. Обработчик обновления добавляется в рамках исправления ошибки. Если ошибка исправляется только в одном хранилище (основном или исправительном), то номер сборки повышается только в нем, если в двух – значит нужно увеличить номер в обоих хранилищах.5.2.2. Обработчик и изменение номера сборки должны помещаться в хранилище в рамках одной закладки. При этом обработчик обновления должен быть «привязан» к тому номеру сборки, который вместе с ним помещается в хранилище.
5.2.3. Если в рамках одной конфигурации обработчики обновления разбиты по технологическим подсистемам (например, в конфигурации 1С:ERP обработчики разбиты на подсистемы УправлениеПредприятием и УправлениеТорговлей), то нужно повышать номер сборки как подсистемы, к которой относится обработчик, так и конфигурации.
5.3. Номер сборки необходимо изменять:
В процедуре ОбновлениеИнформационнойБазы<ИмяБиблиотеки>.ПриДобавленииПодсистемы (только для конфигураций, основанных на Библиотеке Стандартных Подсистем ).Приложение 1. Порядок создания хранилища технического проекта
- Обновить из хранилища конфигурацию информационной базы, подключенную к основному хранилищу
- Создать файл поставки конфигурации основного хранилища (*.cf)
- В информационную базу, которая будет использоваться для работы над техническим проектом, загрузить конфигурацию из файла поставки. После загрузки конфигурации из файла поставки конфигурация будет находиться на поддержке без возможности изменения.
- Создать хранилище конфигурации в соответствующей общей папке (при создании хранилища платформа включит в конфигурации возможность изменения)
- Добавить пользователя ТолькоПросмотр (без пароля, без права захвата объектов). Этого пользователя не нужно использовать для подключения базы к хранилищу – только для обновления из хранилища (получения конфигурации хранилища)
- Добавить в хранилище пользователей, перечисленных в проекте (логин – фамилия сотрудника, без пароля, с правом захвата объектов). Не нужно использовать для работы участников проекта логин пользователя ТолькоПросмотр.
Приложение 2. Порядок обновления хранилища технического проекта до состояния основного хранилища
Перед выполнением переноса изменений из хранилища технического проекта (далее ХТП) в основное хранилище (далее ОХ) выполняется обновление ХТП до состояния ОХ.
Для того чтобы обновить ХТП до состояния ОХ необходимо выполнить следующее:
- Обновить информационную базу, подключенную к ОХ.
- Создать файл поставки конфигурации ОХ.
- Захватить все объекты в ХТП.
- Запустить сравнение основной конфигурации и конфигурации поставщика (Конфигурация – Сравнить конфигурации). Результаты сравнения сохранить в файл – это изменения, внесенные в конфигурацию при работе над техническим проектом. В меню «Действия» выбрать пункт «Отчет о сравнении конфигураций». Для дальнейшего использования лучше вывести и сохранить отчет о сравнении и в текстовом формате и формате табличного документа.
В появившемся окне сравнения и объединения конфигураций нажать кнопку "Фильтр" и установить флажок Показывать только дважды измененные свойства".
На эти объекты нужно обратить внимание при объединении, остальные изменения можно объединять без проверки.
Как было отмечено во Введении, мы будем строить свою учебную конфигурацию "с нуля". Давайте запустим систему. Мы будем считать, что у нас установлена только программная часть системы и нет ни одной ИБ.
Поэтому мы запустим систему в режиме " Конфигуратор ". Для этого воспользуемся классическим способом запуска программ в MS Windows - через кнопку "Пуск" ("Start"): "Пуск - Программы - 1C Предприятие 8.0 - Конфигуратор ".
После чего на экран будет выведен диалог " Запуск 1С:Предприятия".
Каждая ИБ для файлового режима хранения данных характеризуется названием и каталогом, в котором она расположена.
Процесс регистрации новой ИБ в 1С:Предприятии версии 8.0 серьезно переработан по сравнению с версией 7.7, поэтому мы подробно его рассмотрим.
На первом этапе мы определили, что будем создавать новую информационную базу, а не регистрировать уже существующую. Если пойти по второму пути, то достаточно будет только указать, где находится ИБ.
Новой возможностью, которая появилась при создании новой информационной базы, является возможность создавать ИБ из шаблонов.
О том, как создать новый шаблон , написано в книге "1С:Предприятие 8.0. Руководство по установке и запуску".
О том, как создавать ИБ расположенные на сервере "1С:Предприятия", можно прочитать в документации к программе. В этом курсе мы не будем рассматривать этот тип расположения ИБ.
После регистрации необходимо запустить " Конфигуратор ", используя одноименную кнопку.
Окно "Конфигурация"
Окно программы " Конфигуратор " похоже на многие другие программы MS Windows . Здесь есть меню , панели инструментов, рабочая область и строка состояния.
Основным окном, с которым Вам придется иметь дело на протяжении всего сеанса работы с Конфигуратором - это окно " Конфигурация ". (Его можно открыть, используя пункт меню " Конфигурация - Открыть конфигурацию", или нажав на кнопку панели инструментов, которая выполняет те же функции, что и пункт меню .
Это окно содержит объекты, составляющие конфигурацию, которые отображаются в виде дерева. Каждая ветвь этого дерева предназначена для работы с объектами одного типа.
При разработке конфигурации "с нуля", в соответствующие ветви дерева мы будем добавлять новые объекты. При изложении материала мы в основном будем рассматривать прикладные объекты системы, полный список которых можно найти в документации.
Учитывая ограниченный объем данного пособия, мы более-менее подробно рассмотрим следующие типы прикладных объектов: Константы , Справочники, Документы, Отчеты, Регистры сведений и некоторые другие.
Свойства объекта Конфигурации
Каждый из объектов в этом дереве имеет свой набор свойств. Для того чтобы его увидеть, необходимо сначала выделить какой-либо из объектов в дереве, а затем нажать правую кнопку мыши. В открывшемся контекстном меню следует выбрать пункт "Свойства". Сразу после этого будет открыто окно "Свойства".
Основные приемы работы с окнами подробно описаны в документации по системе 1С:Предприятие. Здесь мы рассмотрим работу с этим окном на примере изменения свойств самой Конфигурации как объекта дерева.
Для того чтобы открыть свойства Конфигурации, необходимо на самой Конфигурации как на объекте сделать двойной клик мышью. После чего в Конфигураторе откроется окно "Свойства".
Обратим внимание на то, что все свойства сгруппированы. Для данного объекта таких групп четыре - "Основные", " Представление ", "Разработка" и "Справочная информация ".
Заметим, что состав групп и свойств для каждого из объектов конфигурации был заранее определен еще на этапе разработки программной части системы 1С:Предприятие 8.0. Этот состав не может быть изменен пользователем (или настройщиком системы), но мы можем в Конфигураторе указать конкретные значения для каждого из свойств, определяя тем самым его поведение в режиме 1С:Предприятие.
Файлы к данному курсу Вы можете скачать здесь.
Цель лекции: освоить базовые операции по разработке прикладных конфигураций в среде 1С:Предприятие 8.
1.1. Режимы работы системы, создание информационной базы
Система 1С:Предприятие может работать в двух режимах. Первый называется "1С:Предприятие", второй - " Конфигуратор ". Разработка прикладных решений ведется в конфигураторе , а их исполнение - то есть - работа пользователей с ними - в режиме 1С:Предприятие.
Говоря о системе программ "1С:Предприятие" следует помнить, что существуют понятия " платформа " и " конфигурация ". Платформа - это среда, в которой разрабатывают и исполняют конфигурации . А конфигурацию можно сравнить с набором команд, для исполнения которых нужна платформа .
В области Информационные базы находится список подключенных информационных баз . В данный момент этот список пуст.
Окно содержит следующие кнопки:
- 1С:Предприятие. Запуск системы в режиме 1С:Предприятие.
- Конфигуратор. Запуск системы в режиме Конфигуратор .
- Добавить. Запуск процесса добавления в список новой информационной базы .
- Изменить. Открывает окно изменения параметров добавленной информационной базы .
- Удалить. Удаляет из списка информационную базу .
- Настройка. Позволяет настроить внешний вид списка Информационные базы, установить каталог для поиска шаблонов конфигураций и обновлений.
Нажмем на кнопку Добавить (или ответим Да на вопрос о создании новой базы). Появится окно Добавление информационной базы/группы. Фактически, это мастер, который проводит вас через несколько шагов по добавлению базы в список ( рис. 1.2).
Рис. 1.2. Окно добавления новой информационной базы
Здесь мы можем пойти двумя путями:
- Создание новой информационной базы .
- Добавление в список существующей информационной базы .
Нас интересует именно первый пункт , так как мы должны будем создать базу для последующей разработки в ней учебной конфигурации . Выберем его и нажмем на кнопку Далее. Появится окно, где можно выбрать вариант создания новой информационной базы ( рис. 1.3).
Если ранее вы устанавливали в систему шаблоны каких-либо конфигураций , их перечень можно будет найти в данном окне. Нас готовые конфигурации в данном курсе не интересуют, поэтому мы выбираем вариант создания информационной базы без конфигурации . Он предназначен либо для разработки новой конфигурации , либо для загрузки в пустую конфигурацию выгруженной ранее информационной базы или конфигурации из файла. Нажав в очередной раз кнопку Далее мы попадаем в следующее окно, которое служит для указания наименования и типа расположения базы ( рис. 1.4).
Рис. 1.4. Указание наименования информационной базы и типа расположения
В нашем случае наименованием будет "Основы разработки", тип расположения - На данном компьютере или на компьютере в локальной сети. Второй вариант используется в том случае, если вы имеете дело с сетевой версией программы и собираетесь разместить базу на сервере 1С:Предприятия.
Нажав в очередной раз Далее, мы попадаем в последнее окно добавления информационной базы ( рис. 1.5)
Рис. 1.5. Указание параметров информационной базы
Здесь мы задаем каталог информационной базы и язык.
Нажмем Готово - будет создана пустая информационная база , в списке баз появится название новой базы ( рис. 1.6).
Рис. 1.6. Новая информационная база в окне запуска программы
Обратите внимание на то, что по нажатию кнопки Удалить выделенная информационная база будет удалена лишь из списка стартового окна, но не из системы.
В каталоге только что созданной пустой информационной базы ( рис. 1.7) есть файл 1Cv8.1CD и папка 1Cv8Log. Файл - это и есть информационная база . Сейчас он имеет совсем небольшой размер - 256 Кб. Размер будет расти в ходе разработки конфигурации и ввода данных пользователями системы.
Сейчас, после создания новой пустой конфигурации мы готовы к первому ее запуску в режиме конфигуратора . Выделим ее наименование и нажмем на кнопку Конфигуратор. Откроется окно конфигуратора - оно будет совершенно пустым. Выполним команду меню Конфигурация > Открыть конфигурацию. В левой части окна появится дерево конфигурации ( рис. 1.8).
Деревом конфигурации вы будете постоянно пользоваться при разработке. Можно заметить, что в окне дерева конфигурации уже что-то есть, хотя выше мы создали новую пустую конфигурацию. Дело в том, что здесь представлены лишь пустые группы элементов, которые мы, при работе над нашей учебной конфигурацией, заполним соответствующими объектами .
Конфигурация - это описание структуры данных, на основе которых строится работа пользователя с системой в режиме 1С:Предприятие.
Предположим, нам нужно, чтобы пользователь мог ввести в систему некий документ, который имеет следующие графы (реквизиты, говоря языком 1С:Предприятия):
- Дата;
- Номер документа;
- Ответственное лицо;
- Сумма выручки;
Для этого мы создаем (описываем) в режиме конфигуратора объект Документ, указываем набор его реквизитов, задаем типы данных для этих реквизитов, настраиваем экранные формы документа и другие параметры. В итоге, пользователь системы сможет работать с документом в режиме 1С:Предприятие.
Нередко, говоря о разработке для платформы 1С:Предприятие, применяют термин " программирование ". " Программирование " для 1С:Предприятия - это не только написание программного кода, но и работа в визуальном режиме - создание и настройка объектов , разработка экранных форм, работа с различными конструкторами, ускоряющими процесс разработки. Некоторые действия в ходе разработки можно совершить лишь в визуальном режиме.
Прежде чем начинать изучение конфигурирования, опишем практическую ситуацию, которая легла в основу сквозного примера, а так же рассмотрим некоторые основные приемы работы, которые пригодятся нам в дальнейшем.
В самом простом случае один разработчик захватывает объект конфигурации, а остальные вынуждены ждать, пока этот объект освободится, иначе они не смогут внести изменений в этот объект. Делается это с той целью, чтобы не возникло конфликтов, когда два разработчика одновременно изменяют один и тот же объект конфигурации.
Естественно, это (захват объекта) может продолжаться достаточно долго, пока не завершится разработка, человек и того хуже, может уйти в отпуск, заболеть и забыть отпустить объект конфигурации, а время идет и задачу нужно решать. Если человек длительно отсутствует на рабочем месте, а объект все же нужен прямо сейчас, то выход один - отменять захват объекта администратором хранилища принудительно. В этом случае разработчик, захвативший объект, потеряет изменения, которые он вносил в объект. Мягко говоря, подход «так себе».
- Все говорят – все слушают (параллельный подход):
В более опытной команде разработчиков строится несколько иной подход, когда полностью чистая база данных подключается к хранилищу конфигурации и используется только для получения/помещения изменений, такая база используется только в режиме конфигуратора. Есть своим преимущества, более быстрая реструктуризация конфигурации БД в следствие отсутствия данных в таблицах БД, маленький объем самой базы. После получения изменений из хранилища все изменения сохраняется в файл конфигурации и уже сравнением/объединением (или полной загрузкой) конфигурации переносятся в свою тестовую копию базы с реальными данными, в которой как раз и ведется разработка. После завершения разработки конфигурация из тестовой БД снова сохраняется в файл и сравнением/объединением, с захватом объектов все переносится и помещается в основное хранилище конфигурации.
Преимущества такого подхода – никому не нужно ждать, пока захваченный объект в хранилище освободится, каждый разрабатывает свой функционал отдельно.
Недостатки – чем больше срок между получением файла хранилища конфигурации и переносом своих изменений обратно, тем больше различий в самом хранилище, которые туда уже поместили другие за время разработки, и тем сложнее переносить свои изменения в основное хранилище, особенно в тех местах где разработка пересекалась с другими коллегами в одних и тех же модулях, и объектах. Много галочек, много различий в объектах, изменилась сортировки и порою можно просидеть не один час реального времени, перенося все это, каждый объект нужно просмотреть и учесть всё, чтобы случайно не затереть помещенный ранее код коллег. Здесь принцип «кто успел, тот и съел», то есть кто поместил раньше тебя свои изменения в модуль, тому и проще, ведь это не ему придется сравнивать код двух модулей, объединять его в один и т.д. Если вспомнить, что бывают проекты по 2-3 месяца, то подобный подход при завершении проекта и переносе в основное хранилище покажется сущим адом.
Рассмотрим наиболее выгодный подход для разработчика при работе в крупной команде:
- Все говорят, но я никого не слушаю и делаю по-своему (параллельный подход с минимальным контролем).
Для более простого понимания принципа этой технологи, сначала я буду использовать надуманный пример, на основе не использующейся в реальной жизни конфигурации, код в конфигурации не будет нести какой-либо смысловой нагрузки – это будет просто «какой-то» текст, нам важно понять саму технологию, а не углубляться в понимание того, как правильно писать код или как решить ту или иную задачу с использованием тех или иных сущностей.
Имеем какую-то конфигурацию (собственную, отраслевую или от фирмы 1С не имеет значения).
В частном случае создана конфигурация из трех документов и одного общего модуля
Содержание общего модуля достаточно банальное
Для этой конфигурации создано хранилище.
Разработчик 1 будет в роли негодяя - напрямую подключился из своей тестовой базы к хранилищу и ведет разработку прямо там, мешая другим коллегам параллельно разрабатывать, захватывает объекты пока не закончит свою разработку.
Разработчик 2 устал постоянно ждать на захваченных объектах, начальник ругает, нужно делать работу, а не сидеть сложа руки. Он сохранил конфигурацию в файл и загрузил в свою тестовую базу. Ведет разработку там и не ждет Разработчика 1 или еще кого-либо. Позже перенесет свои наработки в хранилище пусть и с определёнными рисками.
Разработчик 3 пойдет по пути №2, но при этом не будет заботиться и переживать о контроле, он отдаст это механизмам 1С. Создаёт файл поставки от основного хранилища конфигурации. После чего этот файл поставки загружает в свою тестовую базу, поставив её на поддержку.
Загрузив файл поставки в свою тестовую базу, видит, что все объекты находятся на поддержке или, как говорят, «на замке»:
На этом этапе технология разветвленной разработки (п. 4. Разработка технических проектов) гласит - Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».
На самом деле это только Ваше дело, устанавливать правило «Объект поставщика редактируется с сохранением поддержки» точечно или сразу для всей конфигурации целиком. Методологически правильно делать как гласят стандарты, но это долго и, по моему мнению, избыточно, т.к. при разработке проекта часто меняется много объектов сразу. В тот момент, когда потребовалось в процессе разработки поменять, к примеру, общий модуль или модуль объекта, которые ещё на поддержке, нужно открывать окно поддержки конфигурации, пользоваться неудобным поиском, визуально находить нужный объект метаданных, менять свойство снимая с поддержки и т.д. в то время как в голове содержится информация по разработке, и она может вылететь из головы из-за того, что ты отвлекся на лишние действия. Я по своему опыту сразу устанавливаю для всей конфигурации целиком правило «Объект поставщика редактируется с сохранением поддержки», это позволяет мне не снимать точечно в том числе с поддержки те метаданные, которые я изменю в процессе разработки, но в хранилище конфигурации они «на замке» от основного поставщика конфигурации, там я как раз их сниму в процессе переноса и помещения в хранилище точечно, если уже потребуется!
Открываем настройку поддержки конфигурации
И включаем возможность изменения
Устанавливаем правила поддержки
И особо ни о чем не задумываясь начинаем разработку своего проекта или решение своих задач в тестовой базе.
Для примера мы поменяем общий модуль «ОбщийМодульДляВсегоВызовСервера» и «ДокументРазработчика3», добавим свой общий модуль и справочник.
Процедуру, которая имела вид
Мы преобразовали к такому:
В результате чего конфигурация принимает примерно такой вид:
Аналогично поступят Разработчик 1 и Разработчик 2, мы опустим этот момент, скажем лишь то, что Разработчик 1 без особых переживаний сделает это прямиком в хранилище конфигурации с захватом объектов, Разработчик 2 сохранит свой файл конфигурации и перенесет все сравнением/объединением, потратив какое-то количество времени на все это. И наступает наша очередь (мы самые последние) переносить свой проект в хранилище.
За время нашей разработки, открыв хранилище конфигурации, получив все объекты, мы видим, что конфигурация изрядно изменилась:
Но это нас не останавливает и даже не пугает, ведь мы на поддержке. Перед переносом всех изменений в основное хранилище Разработчик 3 повторяет процедуру создания файла поставки конфигурации от основного хранилища и обновляет свою тестовую базу.
Обновление базы из хранилища:
Видим следующую картину обновления
Невооруженным взглядом видно, что изменений достаточно много. Но мы все отдадим на откуп механизмам обновления 1С.
Снимаем отметку в корне конфигурации, тем самым сняв отметки со всех объектов метаданных
И устанавливаем фильтр в режим «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
В данном режиме возвращаем отметку в корне конфигурации, отметив все объекты в этом режиме
И переключаем фильтр в режим «Показывать только дважды измененные свойства»
В данном режиме мы видим, что совместно с другими разработчиками мы изменяли только один общий модуль, объединение которого мы настроим вручную
В данном случае я вношу результирующие изменения, просто добавив их в конкретную процедуру
И на этом все! Если режим «Показывать только дважды измененные свойства» вообще не показал ничего, значит, мест, где пересекалась разработка с другими разработчиками, нет вообще и переживать тем более не о чем!
Устанавливаем правила поддержки для новых объектов, как и ранее, на свое усмотрение:
Получив результирующую конфигурацию, мы имеем в своей базе ни что иное, как "Основная конфигурация хранилища с последними изменениями всех разработчиков + все наши доработки", сохраняем её в файл и без особого труда переносим всё простым сравнением/объединением в основное хранилище конфигурации.
Там (в основном хранилище конфигурации при сравнении/объединении) мы увидим вот такую приятную картину – мы видим только те изменения, которые вносили мы:
Объединяем с хранилищем и понимаем, что мы сократили огромное количество времени и сил.
Таким способом (см. «Обновление базы из хранилища») можно обновлять конфигурацию своей тестовой базы в любой момент времени, перенося к себе изменения, сделанные своими коллегами и уже помещенными в хранилище. Это полезно при длительной разработке какого-то проекта в своей базе, вы переносите чужие изменения и сразу адаптируете свой код под новые условия.
Углубившись в проблему, мы поняли, что в большей степени каждый сам для себя выбирает пути в коллективной разработке. Но кто-то не ищет лёгких путей, а ходит «по натоптанной». Надеюсь материал был Вам полезен, и вы примете на вооружение эту полезную и нужную технологию. Удачной и, главное, легкой вам коллективной разработки. Спасибо за прочтение статьи.
UPD 08.06.2021
Рекомендация - для больших конфигураций все же лучше снимать объекты своей базы с поддержки "точечно", так трехстороннее сравнение при обновлении конфигурации из хранилища происходит в несколько раз быстрее и экономится приличное количество времени, очень хорошо описал эту проблему коллега в комментарии к данной статье "чем больше размеров конфигурация, тем более заметно вы будете это ощущать по времени её обновление".
Еще одна из хороших рекомендаций которая прозвучала в комментариях к статье - если в вашей организации практикуют захват объектов в хранилище на все время изменения, вместо технологии разветвленной разработки, то перед тем как создавать из основного хранилища файл поставки для последующего обновления им локальной базы разработки - в основном хранилище следует захватить доработанные вами объекты заранее, если это конечно возможно. Это нужно, чтобы к моменту переноса доработок на основное хранилище ваши доработанные объекты были доступны для изменения и их не смогли захватить другие разработчики под свои нужды пока вы ведете работу в своей базе.
Читайте также: