Методика постепенного перехода на разработку в 1C:EDT

Схема работы

Чтобы объяснить возможности постепенного перехода на разработку в 1C:EDT, необходимо сделать небольшое отступление о том, как вообще организована групповая разработка в системе 1С:Предприятие 8.

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

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

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

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

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

Говоря о постепенном переходе на разработку в 1C:EDT с использованием системы контроля версий Git, мы будем исходить из того, что текущая разработка прикладного решения выполняется именно по технологии разветвленной разработки конфигураций.

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

Команда проекта 1 работает по-старому. У нее есть хранилище технического проекта 1, в котором она ведет свою разработку, и которое она периодически обновляет до состояния основного хранилища. В конце разработки команда проекта 1 вносит свои изменения в основное хранилище.

Команда проекта 2 работает по-новому. У нее есть Git-репозиторий, который обновляется автоматически до состояния основного хранилища. За это отвечает отдельная служебная конфигурация 1С:ГитКонвертер. Разработчики проекта 2 ведут разработку в 1C:EDT и для версионирования своих изменений используют Git. Это значит, что они используют все новые возможности инструментов разработки, которые предоставляет 1C:EDT, и все возможности децентрализованных систем контроля версий, которые предоставляет Git. Когда разработка проекта 2 закончена, они вносят свои изменения в основное хранилище тем же самым способом, что и разработчики проекта 1, которые работают по-старому.

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

• Не ставит под угрозу критичные технические проекты. Переход на 1C:EDT могут начать те разработчики, у которых в настоящее время есть время и возможность изучить и освоить новую функциональность. Те команды, которые заняты критичными проектами, могут перейти на 1C:EDT позже;
• Можно начать с простых технических проектов. Даже если речь идет об одной команде разработчиков, они могут начать переход на 1C:EDT с более простых проектов, продолжая выполнять сложные проекты по-старому. А по мере приобретения опыта они начнут разрабатывать на 1C:EDT и более сложные проекты;
• Есть время для адаптации существующей инфраструктуры разработки к 1C:EDT и Git. Это касается как программного, так и аппаратного обеспечения. Как правило, в больших проектах существуют вспомогательные программные средства для автоматизации процессов сборки, отладки и тестирования. Они, естественно, настроены на работу с хранилищем конфигурации. Постепенный переход позволяет перенастроить их (или адаптировать) к работе с репозиторием Git, протестировать их работу и убедиться в отсутствии сбоев. Также постепенно можно наращивать мощность компьютеров, которые используют разработчики, потому что работа в 1C:EDT требует больших вычислительных ресурсов по сравнению с работой в Конфигураторе;
• Возможность вернуться к работе по-старому. В случае любых непредвиденных обстоятельств команда разработчиков может создать хранилище проекта, перенести в него конфигурацию из репозитория Git, и вернуться к старой схеме работы. Подробнее об этом вы можете прочитать в разделе Как вернуться к старой схеме работы.

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

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

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

У вас есть выбор из двух вариантов:

• Полностью конвертировать все версии хранилища конфигурации в репозиторий Git, и после этого частично разрабатывать проекты в 1C:EDT. В этом случае в репозитории вы будете обладать всей историей хранилища, но такая полная конвертация может занять значительное количество времени;
• Конвертировать только последнюю версию хранилища конфигурации и после этого частично разрабатывать проекты в 1C:EDT. В этом случае история версий, существующая в хранилище конфигурации, будет недоступна вам в 1C:EDT, однако время до начала частичной разработки в 1C:EDT будет сокращено до минимума. Подробнее о том, как это сделать, вы можете прочитать в документации 1С:ГитКонвертера в разделе Начать работу в EDT, не конвертируя все предыдущие версии хранилища.

Для того, чтобы вы могли оценить технические и временные затраты, приведем несколько примеров из нашего опыта. Методику частичной разработки в 1C:EDT мы используем для нескольких наших конфигураций. Хранилища этих конфигураций мы полностью конвертировали в репозитории Git. В следующей таблице представлены параметры этих конфигураций, параметры компьютеров, на которых выполнялась конвертация, и затраченное время.

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

После этого выберите для себя один из двух вариантов работы, о которых говорилось в начале этого раздела.

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

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

Хранилище технического проекта

В Конфигураторе это хранилище конфигурации.

При работе в 1C:EDT хранилище технического проекта это удаленный репозиторий Git. Подробнее об удаленных репозиториях вы можете прочитать в разделе Удаленные репозитории.

Подключение к хранилищу конфигурации

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

При работе в 1C:EDT аналогичные по смыслу действия выполняются в результате клонирования удаленного репозитория и импорта его данных в проект. Подробнее о клонировании вы можете прочитать в разделе Клонировать репозиторий (clone).

Захват в хранилище

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

При работе в 1C:EDT необходимость подобных действий отсутствует. Вы можете модифицировать любые объекты конфигурации независимо от других разработчиков. Каждый из разработчиков фиксирует свои изменения в своем локальном репозитории независимо друг от друга. Подробнее вы можете прочитать об этом в разделе Зафиксировать изменения в локальном репозитории (commit).

Конкурентная работа в хранилище

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

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

Сравнение и объединение конфигураций

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

При работе в 1C:EDT аналогичные по смыслу действия выполняются при слиянии веток. Подробнее о ветках и их слиянии вы можете прочитать в разделе Ветвление.

Помещение в хранилище

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

При работе в 1C:EDT аналогичные по смыслу действия выполняются командами Коммит... и Push to origin.

Обновление конфигурации из хранилища

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

При работе в 1C:EDT аналогичные по смыслу действия выполняются командой Получить и слить.

Особенности использования репозитория Git для хранения технического проекта

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

Если вы используете методику постепенного перехода на работу в 1C:EDT, когда репозиторий используется для хранения технического проекта, этот «классический» способ использования веток нарушается. Отличие заключается в следующем.

Ветка master используется только для того, чтобы хранить в ней актуальное состояние конфигурации основного хранилища. За это отвечает служебная конфигурация 1С:ГитКонвертер, которая в автоматическом режиме с некоторой периодичностью обновляет состояние ветки master (коммиты Ох1, Ох2 и т.д., «Ох» значит «основное хранилище»). Никакие изменения разработчики в ветку master не вносят и не вливают в нее другие ветки.

Для хранения изменений проекта создается отдельная ветка, на рисунке она называется tech-project/000001. В этой ветке разработчики изменяют конфигурацию (коммиты Пр1, Пр2, Пр3, Пр4, Ф, «Пр» значит «правка», «Ф» значит «финал»).

Периодически разработчики вливают ветку master в ветку tech-project/000001, чтобы иметь у себя актуальное состояние конфигурации основного хранилища (коммиты Сл1, Сл2, СлФ, «Сл» значит «слияние», «СлФ» значит «слияние финал»).

Когда разработка проекта закончена и он протестирован (коммит Ф), конфигурацию из ветки tech-project/000001 необходимо внести в основное хранилище. Для этого в ветку master импортируется последнее состояние основного хранилища (коммит Ох7) и ветка master вливается в ветку tech-project/000001 (коммит СлФ).

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