Технология разветвлённой разработки, использующая git, ci/cd

28.03.23

Разработка - Групповая разработка (Git, хранилище)

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С

Ни для кого не секрет статья на официальном ресурсе ИТС Технология разветвленной разработки конфигураций. Однако, время не стоит на месте, появляются новые инструменты, и требования подлежат пересмотру. Документ не содержит конкретных рекомендаций по используемому программному обеспечению. В качестве CI/CD могут быть использованы любые конвейеры: Jenkins, GitLab CI и т.д. Конечно же требования к разработке ориентированы в первую очередь для работы команды разработки в EDT
Авторские права на картинку принадлежат Vincent Dreissen. База для документа - по ссылке выше - компания ЗАО "1С"
Один из вариантов реализации: Управление сборкой. Расширение для конфигурации СППР (infostart.ru)

Буду раз замечаниям и пожеланиям. 

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

#std709

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

Методическая рекомендация (полезный совет)

Цели внедрения технологии:

  • Повышение качества разрабатываемой конфигурации
  • Повышение культуры разработки и тестирования
  • Обеспечение непрерывного развития конфигураций в условиях жестких сроков разработки

Определения

Репозиторий - хранилище проекта, реализованное по технологии git, включающая в себя

  • Основное
    • Исходные файлы разрабатываемой системы в отдельной корневой папке в формате проекта EDT или формате выгрузки конфигурации в XML 
  • Дополнительно
    • Файлы Unit тестов в отдельной корневой папке 
    • Файлы сценариев функционального тестирования в отдельной корневой папке

Эталонная ИБ - информационная база имеющая структуру исходной конфигурации, взятой за основу, и содержащая некоторый набор данных для тестирования функционала

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

  • Может быть изначально полностью пустой для системы создаваемой с нуля
  • Может не иметь никаких первоначальных данных, либо ограничиваться данными первоначального заполнения обычно такие ИБ создаются с целью запуска в них полного интегрального тестирования.
  • Для каждой ветви репозитория своя эталонная база, имя ветви обязательно должно присутствовать либо в суффиксе, либо в префиксе имени ИБ.
  • При инициализации репозитория для ветвей master, develop она создаётся вручную
  • Для ветвей bugfix/*, tech-project/* в случае отсутствия, копируется из эталонной базы родительских ветвей
  • Для ветви release первоначально копируется из эталонной базы, привязанной к ветви master, далее производится только обновление ИБ.
  • С каждым новым релизом эталонная база ветви master, develop замещается из ветки release (протестированные данные функциональности нового релиза, в совокупности с предыдущими переводятся в основную ветвь)
  • Другие изменения в данных в эталонной ветки базы не предусмотрены.
  • Обновлённая копия эталонной базы, всегда должна являться одним из результатов сборки. 
  • Для веток bugfix и tech-project эталонные ИБ должны быть получены из тех веток, из которых эти ветки были созданы.

Сборка - результат работы конвейера (см. ниже) 

  • Зависит от этапов конвейера, может быть
    • Обновлением копии эталонной информационной базы, ассоциированной с ветвью репозитория для которой производится сборка, при отсутствии информационной базы она автоматически копируется из эталонной ИБ, при наличии обновляется.
    • Создание установочного дистрибутива, либо дистрибутива обновления. Может являться как Continous Delivery так и Continous Deploy 
  • Всегда производится для ветвей:
    • master
      • Этапы build/compile при условии наличия изменений в папке исходного сода системы (src, для EDT). 
      • Этапы deploy, testing, publishing - при любых изменениях в ветви.
    • develop, аналогично master, возможно ограниченное функциональное тестирование, только в рамках изменённых сценариев
    • release, аналогично master, за исключением публикации 
    • bugfix/*tech-project/* аналогично develop

Конвейер - процесс, автоматически запускаемый при изменении состояния веток репозитория. 

  • Для каждой ветви / ветвей подходящих под шаблон может быть настроено различное количество этапов сборки
    • Сборка (build/compile).  
      • Создаётся архив эталонной базы (SQL backup, выгрузка в DT и т.д.) перезаписыванием предыдущего или разностный.
        • Для ветви master предпочтительнее разностный архив, т.к. позволяет восстановить любой предыдущий релиз, и не занимает много места
        • Для других ветвей это может просто архив, замещающий предыдущий.
      • Производится загрузка конфигурации или расширение из файлов XML в эталонную базу. Для формата EDT файлы проекта предварительно конвертируются в формат 1С:Предприятия.
      • Производится запуск информационной базы с параметрами /ЗавершитьРаботуПользователей, либо блокировка работы пользователя любыми другими способами.
      • Производится обновление конфигурации базы данных
      • Производится проверка на необходимость запуска обработчиков обновления, например, запуском внешней обработки запущенной в командной строке одновременно с параметром /ОтключитьЛогикуНачалаРаботыСистемы
      • Если необходимо,
        • Производится запуск информационной базы для отработки обработчиков обновления, дополнительно передаётся параметр /UC ЗапуститьОбновлениеИнформационнойБазы ВыполнитьОтложенноеОбновлениеСейчас РазрешитьРаботуПользователей 
      • Если необходимости в обработчиках нет, производится запуск с параметром /UC РазрешитьРаботуПользователей 
      • В случае возникновения ошибок в процессе сборки или запуска обработчиков обновления создаётся копия неуспешной сборки с суффиксом _fail, а эталонная база восстанавливается из архива.
      • В случае успешной сборки и прохождения обработчиков обновления никаких действий не предпринимается 
    • Распространение (deploy) полученной конфигурацией CF/CFE обновляются необходимые информационные базы: для тестирования, демонстрационные и т.д. 
    • Тестирование (testing) - запуск различного рода тестов
      • Запуск тестирования проводится на копии обновлённой эталонной базы, в которой отработали успешно все обработчики обновления. 
        • В случае, если при тестировании были выявлены ошибки, копия ИБ не уничтожается, ссылки на копию фиксируется в артефактах сборки
        • В случае. если все тесты завершены успешно, копия ИБ удаляется. 
    • Публикация (publishing) передача результатов во внешние источники. Непрерывная передача или развертывание. Этот этап может полностью отсутствовать.
  • Этапы могут быть 
    • Критическими (по умолчанию), в этом случае при обнаружении ошибки линия конвейера останавливается. 
    • Допускающими ошибки, в этом случае ошибки фиксируются в артефакты, а линия конвейера продолжает работу.

Плановая версия конфигурации – версия, содержащая существенное развитие функционала, срок выпуска которой назначается заранее. Формируется в ветке репозитория release, из запросов слияния завершённых и протестированных веток (см. ниже) Технических проектов (tech-project/<номер техпроекта>).

Исправительная версия (bugfix/<номер ошибки>) – версия, которая выпускается при необходимости срочной публикации исправлений критичных ошибок. В исключительных случаях исправительная версия может содержать какой-то новый функционал (например, доработки, связанные с поддержкой изменения законодательства). Срок выпуска определяется при анализе количества и критичности обнаруженных ошибок плановой версии.

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

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

Описание процесса разветвлённой разработки, адаптированной к формату git flow, назначение веток и версий

1. Главная ветка репозитория master

1.1. Длительная, защищённая ветвь. Допускающая изменения только через запросы на слияние.

1.2. Предназначена для хранения историй релизов (версий релизов) разрабатываемой системы, предназначенных для публикации конечному пользователю.

1.3. Фиксации запросов на слияние в главную ветвь репозитория должна осуществляться таким образом, чтобы каждый запрос на слияние переводил ветвь репозитория из одного рабочего (готового к выпуску) состояния в другое. 
Не допускается закладка не полностью отлаженного функционала! Главная ветвь репозитория всегда должна находиться в «неразваленном» состоянии, чтобы в любой момент можно быть начать сборку плановой версии.

1.4. В главной ветви репозитория допускается удовлетворять запросы на слияние из других ветвей репозитория:

  • ветвей исправления критичных ошибок (bugfix/<номер ошибки>), не требующих перепроектирования, объёмного кодирования и тестирования. Если ошибка требует больших переработок и/или пересмотра проектных решений, то исправление такой ошибки должно вестись в рамках технического проекта. Порядок работы с основной ветвью репозитория должен быть таким же, как и для ветвей других технических проектов - через запрос на слияние; 
  • ветки release, где сформирован плановый релиз из технического(их) проекта(ов), прошедший(их) все этапы тестирования; 

1.5. В запросе на слияние конфликты слияния должны отсутствовать.

1.6. Запрещается переносить изменения из других веток методом переноса указателя (fast forward) даже если запрос на слияние позволяет этого сделать

2. Основная разработка.

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

2.2. Основная разработка ведётся в ветви develop, сформированной от ветви master и предназначенной для:

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

2.3. Перед исполнением запроса на слияние производится обязательный code review. Выявленные замечания могут быть основанием для отказа слияния техпроекта.

2.4. В запросах на слияние из веток техпроектов конфликты слияния должны отсутствовать.

2.5. Все фиксации в ветку develop должны содержать комментарий. 

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

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

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

2.7. После переноса изменений в ветвь develop можно исправлять ошибки, наведённые слиянием технического проекта. Для пересмотра проектных решений нужно открывать новый техпроект.

2.8. При сборке плановой версии рекомендуется устанавливать метку (tag) с информацией о номере сборки на фиксацию той версии хранилища, конфигурация которой идёт в сборку. Обычно это последняя на момент сборки закладка. См. схему меток на иллюстрации потока git flow выше.

2.9. Запрещается переносить изменения из других веток методом переноса указателя (fast forward) даже если запрос на слияние позволяет этого сделать.

2.10. Допускается заводить несколько веток при начале разработки новой версии или подверсии, при этом ветка именуется как develop/V.SV.R,  где V.SV.R - планируемый релиз, согласно нумерации редакций и версий.

3. Исправительные версии, ветви вида bugfix/<номер ошибки>

3.1. Фиксирование и исправление ошибок производится на всех этапах разработки и тестирования.

3.2. Ошибки фиксируются в системе отслеживания ошибок (СППР, git issue). Для ошибки фиксируется информационная база, в которой зафиксирована ошибка и ветка, на основании которой конфигурация информационной базы была получена.

3.3. Для выпуска каждой исправительной версии создаётся новая ветка (bugfix/<номер ошибки>) от ветви, в которой была обнаружена.

3.4. Для воспроизведения ошибки создаётся или модифицируется существующий сценарий функционального тестирования, на котором ошибка воспроизводится. Сценарий тестирования размещается в ветке ошибки, затем при успешном тестировании вместе с исправлением сливается в ветку, от которой была сформирована ветка bugfix. В контролируемые ветки (master, develop, release) перенос исправления со сценарием тестирования осуществляется через запрос на слияние. Сценарий тестирования включается в состав функциональных тестов для исключения появления регрессивных ошибок в будущих релизах.

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

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

3.7. Все фиксации в репозиторий исправительной версии должны содержать комментарий. Требования к содержанию комментариев аналогичны требованиям к фиксациям в репозиторий плановой версии (см. п.2.5).

3.8. По окончанию работ с исправительной версией и при условии прохождения необходимых тестов создаётся запрос на слияние в родительскую ветвь. По удовлетворении запроса ветка исправления ошибки, и связанная с ней копия эталонной базы уничтожается. 

3.9. После слияния исправительной версии в исходную ветвь устанавливается метка с информацией о номере сборки +1 относительно той версии, в которой ошибка была обнаружена.

4. Выпуск плановых версий

4.1. Выпуск плановых версий производится в ветви репозитория release.

4.2. Ветвь создаваемая только для выпуска очередного релиза, защищённая.

4.3. В ветви release проводится общее интеграционное тестирование очередной версии, полученной из ветки develop

  • В ветке размещаются и, при необходимости, корректируются сценарии автоматизированного функционального тестирования
  • В случае успешного тестирования функционала ветка сливается в develop и формируется запрос на слияние в master
  • В случае неуспеха (наличия существенных ошибок) ветка release, при необходимости, сливается в develop, а затем уничтожается
  • В случае несущественных, мелких ошибок допускается исправление непосредственно в ветке release
    • Под несущественными ошибками понимается ошибка найденная в терминальном функционале, от которого нет зависимостей:
      • Отчёт
      • Печатная форма
      • Форма объекта метаданных
    • Ещё одним критерием оценки существенности является плановая длительность исправления - не более 2х часов.

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

4.4. Все фиксации в ветку release должны содержать комментарий.
Содержание комментария зависит от характера выполненных работ:

  • при исправлении ошибки обязательно должен быть указан номер и краткое наименование ошибки в системе баг-трекинга;
  • при добавлении новых или изменённых сценариев тестирования должно присутствовать краткое описание произведённых изменений.

5. Разработка технических проектов

5.1. Разработка каждого технического проекта ведётся в отдельных ветках tech-project/NNNN, где NNNN номер техпроекта в системе документации.  Ветвь техпроекта создаётся от последнего зафиксированного изменения ветви develop.
При использовании СППР ветка технического проекта может быть создана автоматически. Если СППР не используется, ветвь технического проекта нужно будет создавать вручную. 

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

На частоту обновления могут влиять следующие факторы:

  • затрагивает ли технический проект объекты других ответственных;
  • проводится ли в данное время рефакторинг общих механизмов;
  • ведётся ли сейчас в других ветвях массовое исправление ошибок.

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

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

В СППР согласовывать сроки встраивания технических проектов можно, используя функциональность контрольных точек по техническому проекту.

5.4. Перед переносом в основное хранилище рекомендуется сжать (sqash) полностью ветвь техпроекта, либо сжать только незначащие фиксации и выполнить перебазирование на ветвь develop, форсируя перезапись ветви в основном репозитории при необходимости, для уменьшения дерева разработки в целом. 

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

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

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

5.7. После проверки переноса изменений в ветви develop, производится запрос на слияние в ветвь release, где производится интеграционное тестирование конфигурации. Проверку нужно проводить с максимальными настройками. См. выше 4. Разработка плановых версий.

5.8. После переноса изменений в ветвь develop, ветвь техпроекта, и связанная с ним эталонная ИБ удаляются из основного репозитория.

5.9. Если в разработке функционала участвуют несколько разработчиков, то каждый из них может создать свои ветки разработки от ветви техпроекта под каждый функциональный участок (feature), а перед переносом выполнить сжатие и перебазирование своей ветки на ветку техпроекта.

6. Нумерация сборок

Изменение номеров версий регламентируется стандартом Нумерация редакций и версий
Здесь будут уточнены правила изменения номера сборки (четвертое число в номере версии) корня конфигурации или разрабатываемой подсистемы. Для корня конфигурации номер сборки хранится в свойствах конфигурации, для встраиваемой библиотеки номер сборки хранится модуле подсистемы и заполняется функцией ПриДобавленииПодсистемы

Изменение сборки фиксируется установкой ярлыка(метки) tag на ту фиксацию, где было увеличен номер сборки основной конфигурации или подсистемы (БСП).

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

6.1. Номер сборки следует увеличивать в случаях:

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

6.2.1. Обработчик и изменение номера сборки должны фиксироваться в хранилище в рамках одной закладки (коммита). При этом обработчик обновления должен быть «привязан» к тому номеру сборки, который вместе с ним помещается в хранилище.

6.2.3. Если в рамках одной конфигурации обработчики обновления разбиты по технологическим подсистемам (например, в конфигурации 1С:ERP обработчики разбиты на подсистемы УправлениеПредприятием и УправлениеТорговлей), то нужно повышать номер сборки как подсистемы, к которой относится обработчик, так и конфигурации.

6.3. Номер сборки необходимо изменять:

  1. В свойствах конфигурации.
  2. В процедуре ОбновлениеИнформационнойБазы<ИмяБиблиотеки>.ПриДобавленииПодсистемы (только для конфигураций, основанных на Библиотеке Стандартных Подсистем).

7. Хранение конфигурации поставщика

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

7.2. Для корректного обеспечения механизмов поддержки рекомендуется создать и поддерживать в актуальном состоянии ветку vendor или stdandart. По мере выхода новых версий поставщика в эту ветку рекомендуется помещать новые релизы и маркировать их метками версий например v3.2.18.6. При этом удобнее не использовать EDT для поддержания ветки в актуальном состоянии, а использовать для этого командную строку приложений 1С:Предприятие, Git и утилиты ring. Последовательность действий следующая:

7.2.1. Создать пустую файловую ИБ

7.2.2. Загрузить из шаблонов конфигурации в пустую базу CF новой конфигурации от поставщика, конфигурацию ИБ обновлять не нужно.

7.2.3. Снять конфигурацию с поддержки.

7.2.4. Утилитой ibcmd (предпочтительнее начиная с платформы 8.3.20) или конфигуратором выгрузить конфигурацию в XML

7.2.5. Утилитой ring (команда ring edt import) преобразовать формат XML в EDT, указав при этом текущую версию платформы проекта. Для ускорения обновления ветки рекомендуется формировать файлы проекта EDT на том же диске. где [будет] размещён проект Git (см. следующий пункт)

7.2.6. Клонировать репозиторий проекта в отдельный каталог, не связанный с EDT если есть существующий каталог проекта Git не использующийся в EDT можно использовать его.

7.2.7. Извлечь ветку поставщика

7.2.8. Удалить папку src и заместить её папкой src полученный в проекте на этапе 6.2.5

7.2.9. Добавить изменения в Git, метку версии поставщика и поместить в удалённое хранилище.

8. Обновление конфигурации поставщика

8.1 Для обновления конфигурации поставщика рекомендуется использовать штатные средства слияния EDT.
8.1.1. Вариант упрощённый, подходит при не больших объёмах изменений.

8.1.1.1. Создать новую ветку версии, например, develop/1.2.1 от master, где 1.2.1 новая версия системы. Слить с веткой поставщика, разрешить конфликты слияния, зафиксировать коммит слияния, провести минимальный рефакторинг и стабилизацию версии. 

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

8.1.2. Вариант при большом объёме рефакторинга. В этом варианте необходимо создаётся дополнительных два проекта EDT в рабочей области, соответствующих базовому коммиту слияния (базовый коммит: git merge-base develop/1.2.1 vendor) и новой конфигурации поставщика (последний коммит в ветке поставщика).

8.1.2.1. Поочерёдно, используя два дополнительных клона git хранилища в одном извлечь ветку вендора, в другой базовый коммит без создания ветки (detached HEAD), присоединить готовые хранилища к EDT, импортировать проекты из них в рабочую область.

8.1.2.2. Провести сравнение объединение, сохраняя файл настроек. При необходимости можно изменить (исправить) исходные модули, например, закомментировав некорректные инструкции препроцессора, чтобы EDT смог по этим модулям провести корректное попроцедурное сравнение/объединение текстов модуля. Если правки затронули дополнительный проект, извлечённый из ветки вендора исправления лучше зафиксировать с отметкой в коммите, что исправлена структура модуля или команды препроцессора с обязательным указанием исправляемой версии V.SV.R.C.

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

8.1.2.4. Сохранить финальные настройки сравнения объединения.

8.1.2.5. Провести слияние с веткой поставщика согласно п.8.1.1.1. применяя сохраненные в п. 8.1.2.4 настройки. Следует учитывать, что при слиянии веток, появятся конфликтные изменения внутренних идентификаторов, которых не было видно при сравнении трёх проектов по базе. Необходимо проанализировать и принять решение относительно каждого из конфликтов по внутренним идентификаторам.

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

ПРИМЕЧАНИЕ. Для удобства префиксы веток кроме основной (master) можно сделать короче BF, TP, Dev, Ven, Std связано с особенностью отображения ярлыков веток в EDT - их длина ограничена. 

Групповая разветвленная разработка EDT стандарт Git

См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9144    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1189    bayselonarrend    3    

37

Автоматизация процесса разработки с помощью сервиса GitFlic

Групповая разработка (Git, хранилище) Бесплатно (free)

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1866    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

Групповая разработка (Git, хранилище) Бесплатно (free)

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3780    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

Групповая разработка (Git, хранилище) Бесплатно (free)

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

22.01.2024    7844    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2774    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

Групповая разработка (Git, хранилище) Бесплатно (free)

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

26.12.2023    1336    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3958    59    salexdv    26    

81
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. morohon 25.02.20 08:35 Сейчас в теме
А подскажите пожалуйста почему много где слышу, что запрещено использовать fast-forward? Вопрос не с подковыркой, правда интересно. Основной момент - это сохранить граф в исходном виде?
2. check2 354 25.02.20 08:48 Сейчас в теме
(1)
сохранить граф в исходном виде
Совершенно верно. Есть два варианта, либо работаем только по FF, но тогда ветка перед слиянием должны сжиматься до одного комита, что не всегда удобно, особенно, если с веткой работают несколько разработчиков. Да и EDT только с версий этого года начал поддерживать сравнение/объединение EDT при перебазировании (т.е. на момент выхода cтатьи есть только RC, которые поддерживают этот режим, ве версии ранее при перебазировании используют EGIT). Если совсем проигнорировать то может поучиться так, что в сливаемых ветках более одного коммита, и после ветвь будет выглядеть не наглядно - не будет понимания где начало того или иного функционала влито.
5. Vladimir Litvinenko 2869 25.02.20 11:10 Сейчас в теме
(2)
Есть два варианта, либо работаем только по FF, но тогда ветка перед слиянием должны сжиматься до одного комита

Речь ведь идёт о git rebase или pull --rebase перед вливанием ветки в мастер/девелоп? В этом случае ведь не обязательно сжимать все изменения до одного коммита. Тогда все новые коммиты из мастер/девелоп сначала применятся к общему предку веток, а затем поверх последнего коммита из мастер/девелоп будут применяться изменения из фича-ветки.

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

что не всегда удобно, особенно, если с веткой работают несколько разработчиков

Перед вливанием фича ветки в общую ветку разработки (мастер/девелоп) разработка в фича-ветке ведь всё равно останавливается. Если возникает ошибка в функционале, реализованном по этой фиче, то по идее нужно bug-fix ветку создавать. Есть ли какое-то неудобство, связанные с количеством разработчиков, кроме того, что разработчиков нужно оповестить при необходимости затянуть изменения в "замороженную" ветку после того как выполнен git rebase и коммиты по фиче сжаты в один?

То есть интересует, видите ли Вы здесь какие-то технические ограничения, или только организационные?


после ветвь будет выглядеть не наглядно - не будет понимания где начало того или иного функционала влито

Здесь имеется в виду процесс очень длительной работы над какой-то фичей? Когда нужно отследить отдельные этапы её реализации?

Если фича-ветка имеет не очень длительную историю, то имеет ли смысл хранить историю отдельных коммитов в неё? А при вливании сжатой фича-ветки в мастер/девелоп можно и тег поставить, и привязка к номеру задачи через комментарий есть. Все изменения и связь с задачей на разработку не теряется. Ну разве что авторство каждой отдельной строки кода может быть потеряно при работе над фичей нескольких разработчиков.

Ведь есть и иная точка зрения, что без ребейза мы как раз приводим ветки в такое состояние, что информация об истории изменений может оказаться чуть ли не бесполезной из-за чрезмерной запутанности https://hackernoon.com/git-merge-vs-rebase-whats-the-diff-76413c117333


P.S. Действительно интересует мнение на этот счет. Сейчас работаю с git, но в основном один, работая над вспомогательными по отношению к разработке на 1С механизмами (внешние обработки, тестовые сценарии, скрипты Jenkins и т.д.). При этом всегда предпочитаю добиваться fast-forward либо сжимая фича-ветку в один коммит перед слиянием, либо делая rebase вместо merge или обычного pull без предварительного сжатия. Хотелось бы более полного понимания, почему те же приёмы могут быть не применимы при разработке на EDT.
6. check2 354 25.02.20 11:54 Сейчас в теме
(5)
В этом случае не обязательно перед ребейзом сжимать все изменения до одного коммита.

Вот этот момент, я в статье не отразил, подумаю как лучше написать, поправлю. Т.к. по сути либо вся ветка develop сделана по FF, и тогда каждое передвижение указателя в develop - это точно добавление нового функционала, а иначе будет
ветвь будет выглядеть не наглядно - не будет понимания где начало того или иного функционала влито
. Поэтому, если FF, то сжато, одним коммитом. Но в любом случае, чтобы в develop прошёл FF, нужно в tech-project сначала сделать rebase, если после точки ветвления были сливы других техпроектов в develop. Либо, второй вариант сохраняем полностью историю ветки tech-project и тогда да, перебазирование делать совсем необязательно. Просто перебазирование - это 100% гарантии, что конфликтов не будет, оно и визуально отображается так же.

Есть ли какое-то неудобство, связанные с количеством разработчиков
Если больше одного разработчика, то с перебазированием есть действительно некоторые трудности, описаны хорошо здесь: Опасности перемещения т.е. технически проблема решается, но создаёт организационные трудности.

По сути, требование к сжатию коммитов вызвано двумя причинами - экономией ресурсов конвейера. Он ведь тоже не резиновый. Меньше коммитов, меньше сборок. Я вот например, люблю в процессе разработки коммитить чуть ли не каждые полчаса, причём отправляю это в удалённый репо, просто для надёжности, вдруг мой SSD упадёт и вместе с ним мой локальный репо? Но вот когда по одной задаче в основную ветку через FF придёт 10 коммитов... Если вернуться к стандартам 1С, то там допускается срать в хранилище техпроекта, но в основное хранилище это попадает одним коммитом (по другому никак :) ). С гитом немного иначе, даже если сделали слияние, то ветка с 10 коммитами всё равно останется. А она нужна в общем графе? Т.е. вторая причина это эстетичность результирующего графа.

Ну и ещё одна сдерживающая использование перебазирование причина - это сам EDT, который при наличии конфликтов во время перебазирования не вызывает диалог сравнения объединения EDT, а использует EGIT. Только с версии 2020.1.0 такая возможность была заявлена (но я её. к примеру ещё не протестировал).
Vladimir Litvinenko; +1 Ответить
7. Vladimir Litvinenko 2869 25.02.20 12:39 Сейчас в теме
(6) Спасибо за ответы. Попробую всё проработать и промоделировать в новом EDT как время появится.

Ранее уже пробовал все эти операции проделывать, но тогда оказалось, что проще через git bash ребейз выполнять и потом в Visual Studio Code конфликты разрешать. А потом уже в EDT перечитывать репозиторий. В EDT тогда с этим постоянно ошибки возникали. Сейчас Вы написали, что функционал доработали, поэтому столько вопросов появилось. Надо будет прорабатывать эту информацию.

Про количество сборок на CI при ребейзе без предварительного сжатия - это очень полезная информация. Я пока что только при работе с хранилищем CI делал и как-то даже не задумывался о таком моменте.
9. check2 354 25.02.20 14:06 Сейчас в теме
(7) Смотрите, попробуйте сымитировать такую проблему: изменение одного макета или формы документа в двух ветках и потом сделайте перебазирование одной на другую. Не знаю как штатный git rebase, скорее всего он просто прервёт операцию перебазирования. Но EGIT, знаю точно, делает очень плохо. Он работает с макетами *.mxlx и формами *.mdo как с обычным текстом, и после его слияния формы становятся полностью не работоспособны. Если был конфликт, то он в текст вставляет строки >>>>>>>>HEAD <<<<<<<<<<<<TAIL и т.д. Правда, надо отметить что касается mxlx то и EDT не особо предложит варианты слияния - либо взять справа, либо слева. Т.е. если по факту в макете конфликт, то до слияния нужно учесть все изменения ветки, куда производится перебазирование. Ну вот хоть формы объектов EDT сливает гораздо лучше EGIT. Там сейчас практически всё, о чем мечтали в конфигураторе.
Vladimir Litvinenko; +1 Ответить
3. muskul 25.02.20 09:00 Сейчас в теме
Почему везде пишут и слышно про качество разработки. Но качество выпускаемых релизов и ошибок доходит до абсурда
4. check2 354 25.02.20 09:44 Сейчас в теме
(3) Основная причина - жадность руководства. Качество, это дополнительное время = деньги. И, как это не печально, в итоге получается как у Вовочки в три девятом царстве. Стандарты разработки - это культура, но следовать им не просто.
Vladimir Litvinenko; ivanov660; +2 Ответить
8. Vladimir Litvinenko 2869 25.02.20 13:01 Сейчас в теме
(3) Про качество разработки обычно пишут разработчики, а не менеджеры от бизнеса.

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

Разница между "мы работаем над техническим качеством" и "мы обеспечиваем качество, нужное заказчику" очевидна. Особенно с учётом того, что в программном продукте обычно гораздо больше ошибок и недоработок, чем плавают на поверхности. Раз так в 10 больше, в лучшем случае ;))
10. check2 354 25.02.20 14:18 Сейчас в теме
(8)
почему этими вопросами не нужно заниматься пока совсем не припрёт
Это из серии "фигню" не лечим, а пц закроем иском в суде. Есть среди РП такая тактика закрыть основные этапы проекта (разработка) пока всё мутно, всё г-но скинуть на последний этап, а потом по суду закрыть проект... Имидж ничто - жажда всё. Печально на самом деле это очень. Вся надежда на интенсификацию труда и повышению его КПД с использованием механизмов и методик.
Оставьте свое сообщение