В чём разница Build и Release?

Разница между Build и Release в разработке ПО

В контексте жизненного цикла разработки ПО (SDLC) термины Build и Release обозначают принципиально разные этапы, хотя и тесно взаимосвязаны. Понимание этой разницы критически важно для построения эффективных процессов CI/CD, управления версиями и взаимодействия между командами разработки, тестирования и эксплуатации.

Build (Сборка)

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

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

    *   **Технический процесс**: Включает компиляцию, линковку, минификацию, транспиляцию, упаковку зависимостей.
    *   **Частота**: Очень высокая. Сборки могут запускаться десятки или сотни раз в день (например, при каждом коммите в репозиторий — CI).
    *   **Контекст**: Внутренний процесс для команды разработки и QA. Сборка не предназначена для конечных пользователей.
    *   **Идентификация**: Обычно имеет уникальный **номер сборки (Build Number)**, часто автоматически инкрементируемый системой сборки (Jenkins, GitLab CI, GitHub Actions).
    *   **Результат**: Артефакт (`.jar`, `.exe`, `.apk`, `.dmg`, Docker-образ), который попадает в артефакт-репозиторий (Nexus, Artifactory).

Пример сценария и кода: Разработчик делает коммит. CI-сервер (например, Jenkins) автоматически запускает задачу сборки.

// Пример упрощенного Jenkins Pipeline (Declarative Pipeline) для создания сборки
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/your-company/your-app.git'
            }
        }
        stage('Build') {
            steps {
                // Для Java-проекта
                sh './mvnw clean compile package'
                // Или для Node.js
                // sh 'npm run build'
            }
        }
        stage('Archive Artifact') {
            steps {
                archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
            }
        }
    }
}

Результат: файл my-app-1.0.0-SNAPSHOT.jar (Build #45) загружен в Nexus. Эта сборка готова для развертывания на тестовый стенд.

Release (Релиз, Выпуск)

Release — это процесс подготовки, проверки и предоставления стабильной и протестированной версии ПО конечным пользователям. Релиз — это не артефакт, а событие или версия.

• Основная цель: Доставить новую функциональность, исправления или улучшения пользователям безопасным и контролируемым образом.
• Ключевые характеристики:

    *   **Бизнес-процесс**: Включает не только техническое развертывание, но и планирование, тестирование, создание заметок о выпуске (Release Notes), коммуникацию, маркетинг, поддержку.
    *   **Частота**: Значительно ниже, чем у сборок (еженедельно, раз в две недели, ежемесячно). Зависит от методологии (Agile/Waterfall).
    *   **Контекст**: Публичный процесс, ориентированный на пользователя или заказчика.
    *   **Идентификация**: Имеет **семантический номер версии (Semantic Versioning)**, например, `v2.1.0`. Этот номер маркирует конкретную сборку, выбранную для релиза.
    *   **Результат**: Стабильная версия ПО, развернутая в production-среде, и сопутствующие материалы (релизные заметки, обновления документации).

Пример сценария: Команда решает, что накопленный набор функций в сборках #78-#95 готов для показа клиентам. Ответственное лицо (Release Manager) создает ветку release/v1.2.0 из главной ветки, проводит финальное регрессионное тестирование сборки #95, подписывает ее и присваивает ей версию v1.2.0. Затем эта версия разворачивается на production-серверах.

Сравнительная таблица Build vs Release

Взаимосвязь в конвейере CI/CD

В современных практиках DevOps эти понятия объединяются в единый автоматизированный поток:

1. Непрерывная интеграция (CI): При каждом коммите создается Build.
2. Непрерывная поставка (CD): Успешно прошедшая все автоматические тесты сборка автоматически разворачивается на тестовые среды. Когда сборка получает одобрение (например, после manual-тестирования), ее можно вручную или автоматически выпустить (Release) в production. Эта сборка и становится публичной версией.

Вывод: Проще всего запомнить так: Build — это "как мы это делаем" (технический процесс создания ПО), а Release — это "что и когда мы отдаем" (управленческое и бизнес-событие поставки готового продукта). Каждый релиз основан на конкретной, одобренной сборке, но далеко не каждая сборка становится релизом.