Постепенный переход на разработку в 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, и вернуться к старой схеме работы. Подробнее об этом вы можете прочитать в разделе Как вернуться к "старой" схеме работы.
Важно: Если для групповой разработки вы используете единственное хранилище конфигурации, или вы используете несколько хранилищ, но по собственной технологии, то для постепенного перехода на разработку в 1C:EDT вам нужно будет выделить некоторую логическую область разработки, которая может существовать некоторое время относительно независимо. И дальше перевести эту область на разработку в 1C:EDT в соответствии с тем, как это описано дальше.