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

Публикация № 1199555

Методология - Методология управления разработкой

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

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

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

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

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

#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) даже если запрос на слияние позволяет этого сделать.

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

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. morohon 25.02.20 08:35 Сейчас в теме
А подскажите пожалуйста почему много где слышу, что запрещено использовать fast-forward? Вопрос не с подковыркой, правда интересно. Основной момент - это сохранить граф в исходном виде?
2. check2 124 25.02.20 08:48 Сейчас в теме
(1)
сохранить граф в исходном виде
Совершенно верно. Есть два варианта, либо работаем только по FF, но тогда ветка перед слиянием должны сжиматься до одного комита, что не всегда удобно, особенно, если с веткой работают несколько разработчиков. Да и EDT только с версий этого года начал поддерживать сравнение/объединение EDT при перебазировании (т.е. на момент выхода cтатьи есть только RC, которые поддерживают этот режим, ве версии ранее при перебазировании используют EGIT). Если совсем проигнорировать то может поучиться так, что в сливаемых ветках более одного коммита, и после ветвь будет выглядеть не наглядно - не будет понимания где начало того или иного функционала влито.
5. Vladimir Litvinenko 2330 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 124 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 2330 25.02.20 12:39 Сейчас в теме
(6) Спасибо за ответы. Попробую всё проработать и промоделировать в новом EDT как время появится.

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

Про количество сборок на CI при ребейзе без предварительного сжатия - это очень полезная информация. Я пока что только при работе с хранилищем CI делал и как-то даже не задумывался о таком моменте.
9. check2 124 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 124 25.02.20 09:44 Сейчас в теме
(3) Основная причина - жадность руководства. Качество, это дополнительное время = деньги. И, как это не печально, в итоге получается как у Вовочки в три девятом царстве. Стандарты разработки - это культура, но следовать им не просто.
Vladimir Litvinenko; ivanov660; +2 Ответить
8. Vladimir Litvinenko 2330 25.02.20 13:01 Сейчас в теме
(3) Про качество разработки обычно пишут разработчики, а не менеджеры от бизнеса.

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

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

См. также

1C:Enterprise Development tools (EDT) или кодим в Eclipse Промо

EDT v8 Бесплатно (free)

Как и выход мобильной платформы был для оооочень большого числа разработчиком открытием, так и я уверен, что и о новом конфигураторе - тоже мало кто слышал. Поэтому давайте попробуем пробежаться по новому конфигуратору. (Много больших картинок)

11.04.2015    76148    0    DitriX    297    

Что такое качество разработки и качество поддержки? Статья 2

Методология управления разработкой Проектирование Бесплатно (free)

Это вторая из 8 статей про разработку в сфере 1С. В данной статье будут раскрыты следующие вопросы: 1. Ошибки в решениях в пользовательском режиме и их причины. 2. Технические ошибки при разработке решений в 1С. 3. Мы закрыли 100 заявок за 1 день. Есть ли польза от такой поддержки? Польза или вред от SLA.

30.06.2020    818    0    biimmap    5    

Unit-тесты с помощью 1C:Enterprise Development Tools

EDT v8 Бесплатно (free)

Концепция TDD требует перестроения подходов к разработке и наличия инструментов для запуска Unit-тестов. Про написание плагина для EDT, который содержит в себе инструменты написания, анализа результатов и запуска Unit-тестов для конфигураций 1С на конференции Infostart Event 2019 Inception рассказал ведущий специалист по внедрению компании 1С-Рарус Александр Капралов.

11.06.2020    2819    0    doublesun    6    

Мастер-класс "Ведение проектов в типовых конфигурациях 1С"

Управление проектом CI/CD БСП (Библиотека стандартных подсистем) v8 Бесплатно (free)

При адаптации типовой конфигурации под особенности учета в компании важно обеспечить возможность легкого обновления поставки. Как организовать архитектуру решения и продумать процесс быстрой и эффективной разработки без ущерба типовой функциональности, на конференции Infostart Event 2019 Inception рассказал ведущий программист компании BIA-Teсhnologies Алексей Князьков.

05.06.2020    3171    0    AKnyazkov    3    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    9680    0    MariaTemchina    33    

Установка EDT 2020.2 на Ubuntu 18.04

EDT Россия Бесплатно (free)

Установка EDT 2020.2 на Ubuntu 18.04 Заметки на будущее.

12.04.2020    1949    0    awk    14    

Enterprise Development Tools, версия 2020.2 для мобильной разработки. Бег по граблям (серия публикаций от чайника для чайников)

EDT v8::Mobile 1cv8.cf Бесплатно (free)

Небольшие советы, которые сберегут время при работе с Enterprise Development Tools, версия 2020.2.

10.04.2020    3726    0    capitan    8    

Визуализация фич Vanessa Automation в StoryMapper

Agile (XP, SCRUM, Канбан) Сценарное тестирование Vanessa Automation ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    2407    0    oleynik.dv    7    

Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 4

DevOps CI/CD Jenkins v8 Бесплатно (free)

Выполним основные настройки Jenkins как CI-сервера. Подключим к нему развёрнутые через Vagrant виртуальные машины в качестве сборочных узлов.

13.03.2020    4353    0    Vladimir Litvinenko    7    

Разворачиваем узлы CI через Vagrant, строим сеть из виртуальных машин. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 3

DevOps CI/CD Linux Бесплатно (free)

Разворачиваем инфраструктуру для CI из образов виртуальных машин.

04.03.2020    3853    0    Vladimir Litvinenko    14    

Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 2

DevOps CI/CD Linux Бесплатно (free)

Автоматизируем установку и конфигурирование Linux, PostgreSQL, 1C, Apache, Java с возможностью выбора версий дистрибутивов. Упаковываем результат в образ виртуальной машины.

28.02.2020    6806    0    Vladimir Litvinenko    11    

CI/CD для 1С проектов, унифицировано, с кастомизацией

CI/CD Инструментарий разработчика Бесплатно (free)

Тема CI/CD в связке с 1С не нова, но многих пугает сложность использования и поддержки, необходимость обучения команды. Про то, как унифицировать и упростить поддержку сборочных конвейеров для большого количества решений, в своем докладе на конференции Infostart Event 2019 Inception рассказал начальник отдела компании BIA-Technologies Валерий Максимов.

20.02.2020    5396    0    theshadowco    11    

О синхронизации ИБ с проектом в EDT

EDT Бесплатно (free)

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

19.02.2020    3073    0    check2    2    

EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 03

EDT v8 Бесплатно (free)

Групповая разработка в EDT.

21.01.2020    3852    0    YuriYuriev    3    

EDT + УТ 11.4 + БП 3.0 + Расширения. Часть 02

EDT v8 Бесплатно (free)

Продолжение "путевых заметок" про EDT...

09.01.2020    5553    0    YuriYuriev    30    

EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 01

EDT v8 Бесплатно (free)

...продолжаем мучить(ся с) EDT

28.12.2019    5902    0    YuriYuriev    8    

BDDSM-практики, или 50 оттенков желтого

Методология управления разработкой Vanessa Automation ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    7780    0    Mistress_A    28    

EDT 1.16. Первые 20 часов работы

EDT v8 Россия Бесплатно (free)

Первое знакомство с 1C:Enterprise Development Tools, версия 1.16.0.363.

25.12.2019    9936    0    YuriYuriev    11    

GitSync 3.0. Шпаргалка по использованию

Git (GitHub, GitLab, BitBucket) Бесплатно (free)

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

26.11.2019    6555    0    -vito-    29    

Git для 1С-ника и другие технологии групповой разработки

Инструментарий разработчика Git (GitHub, GitLab, BitBucket) v8 1cv8.cf Россия Бесплатно (free)

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

28.10.2019    11754    0    stas_ganiev    16    

Переход на разработку с хранением в Git, часть 1, подготовка репозитория

Хранилище Git (GitHub, GitLab, BitBucket) v8 1cv8.cf Россия Бесплатно (free)

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

29.09.2019    7628    0    malikov_pro    14    

Как мы разрабатываем в EDT

EDT Инструментарий разработчика v8 Бесплатно (free)

EDT – это новая среда разработки, на которую сейчас перешли разработчики фирмы «1С». Однако до сих пор существует ряд «белых пятен», касающихся как теоретической, так и практической части применения этого инструмента. Про опыт перехода на разработку в EDT на конференции INFOSTART EVENT 2018 EDUCATION рассказал начальник сектора разработки в компании «Группа Полипластик» Владимир Крючков.

23.08.2019    11340    0    ivanov660    24    

1С:EDT. Первые шаги… или есть ли альтернатива конфигуратору?

EDT v8 Бесплатно (free)

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

15.08.2019    20722    0    ellavs    105    

[Заметки] Scrum за 5 минут

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    8088    0    leobrn    11    

Взгляд на практику разработки в EDT из зазеркалья

EDT v8 1cv8.cf Бесплатно (free)

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

26.07.2018    23539    0    ivanov660    114    

WSSpeedTest - обработка измерения скорости работы web сервера

EDT v8 1cv8.cf Россия Бесплатно (free)

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

20.12.2010    12739    0    nafa    4