Термины, связанные с ветками
Основная ветка (main/master)
Ветка
Главная ветка репозитория, содержащая только стабильный код, соответствующий версиям, развернутым у пользователей. Каждый коммит в эту ветку представляет собой новый релиз.
Пример: Ветка main содержит теги v1.0.0, v1.1.0, v1.1.1 - все версии, которые были поставлены клиентам.
Ветка разработки (develop)
Ветка
Ветка интеграции, куда сливается весь новый функционал для тестирования и стабилизации. Содержит код для следующего крупного релиза.
Пример: Разработчики сливают завершенные функциональные ветки в develop для интеграционного тестирования.
Функциональная ветка (feature branch)
Ветка
Короткоживущая ветка для разработки отдельной функции или улучшения. Создается от develop и вливается обратно после завершения работы.
Пример: feature/integration-with-bank-client - ветка для разработки интеграции с банк-клиентом.
Релизная ветка (release branch)
Ветка
Ветка для стабилизации релиза. Создается от develop когда накоплено достаточно функционала для нового релиза. На этой стадии запрещено добавлять новый функционал.
Пример: release/v2.0.0 - ветка для подготовки версии 2.0.0 к выпуску.
Ветка исправлений (hotfix branch)
Ветка
Ветка для экстренного исправления критических ошибок в продакшене. Создается от main и вливается обратно в main и develop.
Пример: hotfix/critical-calculation-error - ветка для срочного исправления ошибки в расчетах.
Термины, связанные со стадиями
Публичный релиз (Public Release)
Стадия
Стабильная версия программного обеспечения, которая прошла все этапы тестирования и готова к поставке конечным пользователям.
Пример: Версия 2.1.0, размещенная на сайте для скачивания и развертывания у клиентов.
Релиз-кандидат (Release Candidate - RC)
Стадия
Предрелизная версия, которая содержит весь планируемый функционал и проходит финальное тестирование перед выпуском.
Пример: v2.1.0-rc1, v2.1.0-rc2 - последовательные кандидаты на релиз, проходящие тестирование.
Стадия стабилизации (Stabilization Phase)
Стадия
Период между созданием релизной ветки и публичным релизом, когда фокус смещается с разработки нового функционала на исправление ошибок и подготовку к выпуску.
Пример: 2-недельный период перед выпуском версии 2.0.0, когда команда исправляет только критические баги.
Стабильная версия для разработки (Stable Development Version)
Стадия
Версия в ветке develop, которая проходит все автоматические тесты и готова к началу цикла выпуска релиза.
Пример: Состояние ветки develop после успешного прохождения всех автоматических тестов.
Термины, связанные с процессами
Синхронизационное слияние (Sync Merge)
Процесс
Процесс регулярного слияния изменений из родительской ветки в feature-ветку для минимизации расхождений и будущих конфликтов.
Пример: Ежедневное обновление feature-ветки из develop для получения последних изменений от других разработчиков.
Код-ревью (Code Review)
Процесс
Процесс проверки кода другими разработчиками перед слиянием в основную ветку для обеспечения качества и соответствия стандартам.
Пример: Обязательная проверка всех pull request'ов старшим разработчиком перед слиянием в develop.
Интеграционное тестирование (Integration Testing)
Процесс
Тестирование взаимодействия между различными компонентами системы после их объединения.
Пример: Автоматические тесты, запускаемые после каждого слияния в develop для проверки взаимодействия модулей.
Непрерывная интеграция (Continuous Integration - CI)
Процесс
Практика регулярного слияния изменений кода в общую ветку с автоматической сборкой и тестированием.
Пример: Jenkins сервер, который автоматически собирает и тестирует каждое изменение в develop.
1С-специфичные термины
Важно: Эти термины учитывают особенности платформы 1С, которые отличают процесс разработки от общего подхода к разработке ПО.
Конфигурация (Configuration)
1С-специфика
Набор метаданных, модулей и других объектов, определяющих функциональность приложения на платформе 1С.
Пример: Конфигурация "Управление торговлей" содержит метаданные документов, справочников, отчетов и их программные модули.
Хранилище конфигурации (Configuration Storage)
1С-специфика
Централизованное хранилище версий конфигурации, обеспечивающее совместную работу нескольких разработчиков.
Пример: База данных или файловое хранилище, к которому подключаются разработчики для получения и выгрузки изменений.
Выгрузка/Загрузка изменений (Check-out/Check-in)
1С-специфика
Процесс получения изменений из хранилища (выгрузка) и отправки изменений в хранилище (загрузка) в 1С.
Пример: Разработчик выгружает последние изменения из хранилища перед началом работы и загружает свои изменения после завершения задачи.
Файл конфигурации (.cf)
1С-специфика
Бинарный файл, содержащий полную конфигурацию для распространения и установки на рабочие базы.
Пример: UT_11.4.10.125.cf - файл конфигурации "Управление торговлей" версии 11.4.10.125.
Файл обновления (.cfu)
1С-специфика
Файл с частичными изменениями конфигурации, используемый для обновления существующих баз данных.
Пример: update_11.4.9_to_11.4.10.cfu - файл обновления с версии 11.4.9 до 11.4.10.
Монолитная конфигурация (Monolithic Configuration)
1С-специфика
Конфигурация, в которой все изменения вносятся непосредственно в основную конфигурацию, а не через подсистемы или расширения.
Пример: Большинство типовых конфигураций 1С являются монолитными, что усложняет процесс слияния изменений.
Термины, связанные с тестированием
Модульное тестирование (Unit Testing)
Тестирование
Тестирование отдельных модулей или компонентов системы в изоляции от остальных частей.
Пример: Тестирование функции расчета скидки в модуле документа "РеализацияТоваровУслуг".
Регрессионное тестирование (Regression Testing)
Тестирование
Тестирование, направленное на проверку того, что новые изменения не нарушили существующую функциональность.
Пример: Запуск всех автоматических тестов после слияния feature-ветки в develop.
Приемочное тестирование (Acceptance Testing - UAT)
Тестирование
Финальное тестирование, проводимое перед выпуском, чтобы убедиться, что система удовлетворяет требованиям заказчика.
Пример: Тестирование релиз-кандидата v2.1.0-rc2 бизнес-аналитиком на тестовой базе с реальными данными.
Тестовое покрытие (Test Coverage)
Тестирование
Метрика, показывающая процент кода, который выполняется при запуске тестов.
Пример: "Наш проект имеет 75% тестовое покрытие - 75% строк кода выполняются в автоматических тестах".
Антипаттерны и частые ошибки
Прямые коммиты в main
Разработчики напрямую коммитят изменения в основную ветку, минуя процесс код-ревью и тестирования.
Решение: Запретить прямые коммиты в main, использовать pull request'ы и обязательное код-ревью.
Долгоживущие feature-ветки
Feature-ветки существуют слишком долго (более 2-3 недель), что приводит к сложным конфликтам при слиянии.
Решение: Разбивать большие задачи на более мелкие, регулярно синхронизироваться с develop.
Слияние без тестирования
Изменения сливаются в develop без предварительного тестирования, что приводит к нестабильности ветки разработки.
Решение: Внедрить автоматическое тестирование перед слиянием, требовать успешного прохождения тестов.
Отсутствие резервных копий перед слиянием
Разработчики не создают резервные копии конфигурации перед сложными операциями слияния в 1С.
Решение: Обязательное создание бекапа конфигурации перед загрузкой изменений в хранилище.
Игнорирование конфликтов при ежедневных слияниях
Разработчики откладывают разрешение конфликтов, что приводит к накоплению проблем.
Решение: Регулярная синхронизация (минимум раз в день) и немедленное разрешение конфликтов.