18.02.2025 07:32
stepanov_alex01 0 1800 Источник

Когда-то, несколько назад, я впервые столкнулся с вопросом: «А как нам быстрее выпускать фичи и при этом не терять в качестве?» Тогда мы начинали использовать простейшие скрипты для автоматической сборки и запускали тесты вручную. Со временем требования росли, проекты усложнялись, и стало очевидно, что нужен более системный подход. Так в мою жизнь вошли современные CI/CD-практики. Сегодня я хочу поделиться опытом и рассказать, как организовать качественный и быстрый процесс выпуска кода, используя современные инструменты и подходы.

Зачем нужны CI/CD-практики

CI (Continuous Integration, непрерывная интеграция) — это методология, при которой все изменения в репозитории проходят автоматические проверки: сборку, юнит-тесты, статический анализ кода и многое другое. Цель — поймать проблемы на ранних стадиях, пока их исправление не требует существенных затрат времени и сил.

CD (Continuous Delivery или Continuous Deployment) — это набор практик, который обеспечивает автоматическое развертывание (либо готовность к развертыванию) в различные окружения: стейджинг, тестовые среды, а затем и в продакшн. При этом важно, чтобы итоговый релиз был стабильным и проверенным на всём пути доставки.

Главная задача — сократить «time to market», то есть время от момента, когда разработчик написал фичу, до момента, когда она попадает в руки реальных пользователей. При этом качество кода не должно падать — наоборот, уровень автоматизированного контроля растёт.

Основные шаги в конвейере CI/CD

Обычно конвейер поставки кода состоит из нескольких этапов:

  1. Сборка (build)

    • Зависимости: установка всех необходимых пакетов, библиотек.

    • Компиляция: сборка кода проекта, минификация или упаковка ресурсов.

  2. Тестирование (test)

    • Юнит-тесты: проверка корректности отдельных модулей.

    • Интеграционные тесты: проверка взаимодействия нескольких компонентов.

    • Нагрузочные (перформанс) тесты: определение, как система ведёт себя под высокой нагрузкой.

    • Безопасностные тесты: сканирование уязвимостей, проверка соответствия стандартам безопасности.

  3. Сканирование кода (code analysis)

    • Статический анализ: поиск типичных ошибок, потенциальных утечек памяти, несоответствий код-стилю.

    • Линтинг: форматирование кода согласно общепринятым правилам.

  4. Развёртывание (deploy)

    • Автоматизированный деплой в тестовые окружения.

    • При необходимости ручная проверка (staging).

    • Автоматизированный деплой в продакшн (или полуавтоматический: с «запросом на подтверждение»).

Современные инструменты и решения

Jenkins

Jenkins до сих пор остаётся одним из самых популярных инструментов CI/CD. Он хорош своей гибкостью и огромной экосистемой плагинов. На практике я часто сталкивался с тем, что Jenkins используют в крупных компаниях, где много легаси и инфраструктурного разнообразия.

Пример Jenkinsfile:

pipeline {
 agent any
stages {
    stage('Checkout') {
        steps {
            git url: 'https://git.example.com/myproject.git'
        }
    }
    
    stage('Build') {
        steps {
            sh './gradlew build'
        }
    }
    
    stage('Test') {
        steps {
            sh './gradlew test'
        }
    }
    
    stage('Deploy') {
        steps {
            echo 'Deploying to staging...'
            // Здесь логика деплоя
        }
    }
}
}

GitLab CI/CD

GitLab предлагает встроенные инструменты для CI/CD, что упрощает настройку в рамках одного экосистемного решения. Основная сила GitLab CI/CD в том, что всё хранится рядом с кодом в виде .gitlab-ci.yml, и при этом легко можно распределить раннеры (исполнительные агенты) по разным серверам.

Пример .gitlab-ci.yml:

stages:

  • build

  • test

  • deploy

build:
stage: build
script:
- npm install
- npm run build
artifacts:
paths:
- dist/

test:
stage: test
script:
- npm run test

deploy:
stage: deploy
script:
- echo "Deploying to production..."
# Логика деплоя (scp, kubectl, docker, etc.)
only:
- main

GitHub Actions

GitHub Actions завоёвывает популярность благодаря глубокой интеграции с GitHub. Он очень удобен, если репозиторий уже хранится на этой платформе. Плюс есть обширный Marketplace с готовыми экшенами (действиями), что экономит время на настройку.

Пример использования GitHub Actions в .github/workflows/ci.yml:

name: CI

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v2
  - name: Install dependencies
    run: npm install
  - name: Build
    run: npm run build

test:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v2
  - name: Install dependencies
    run: npm install
  - name: Test
    run: npm run test

Другие решения

  • CircleCI: простой в настройке, часто выбирают для проектов на JavaScript, Ruby, Python.

  • Travis CI: исторически один из первых облачных сервисов для CI, сейчас несколько уступает конкурентам, но всё ещё актуален.

  • Drone CI: решение на Go с контейнерной архитектурой, упрощает масштабирование.

Автоматизация тестирования: от юнит-тестов до нагрузочных

Современные проекты требуют разных уровней тестирования. Если десять лет назад многим было достаточно «прогнать юнит-тесты», то сейчас ожидания к качеству гораздо выше.

Юнит-тесты

Юнит-тесты — фундамент. Именно они позволяют быстро понять, не сломалась ли базовая логика приложения. Для Python-проектов часто используют pytest, для JavaScript — Jest или Mocha, для Java — JUnit или TestNG. Хорошим тоном считается, когда юнит-тесты работают быстро и покрывают большой процент кода (хотя сам процент не всегда говорит о качестве).

Пример юнит-теста на JavaScript с использованием Jest:

// sum.js
function sum(a, b) {
return a + b;
}
module.exports = sum;

// sum.test.js
const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});

Интеграционные тесты

После юнит-тестирования важно проверить взаимодействие между сервисами. Например, если у вас микросервисная архитектура, нужно удостовериться, что сервис А правильно обменивается данными с сервисом Б. Здесь часто используют TestContainers (для Java), Docker Compose и другие инструменты, которые позволяют поднимать временное окружение на время теста.

Пример интеграционного теста (Java + Spring Boot + Testcontainers):

@SpringBootTest
@AutoConfigureMockMvc
@Testcontainers
public class IntegrationTest 

{
@Container
public static PostgreSQLContainer postgres = new PostgreSQLContainer<>("postgres:13");

@Autowired
private MockMvc mockMvc;

@Test
void testCreateUser() throws Exception {
    mockMvc.perform(post("/users")
            .contentType(MediaType.APPLICATION_JSON)
            .content("{\"name\":\"John\",\"email\":\"john@example.com\"}"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.id").exists());
}
}

Нагрузочные (перформанс) тесты

В проектах, где важна производительность, без нагрузочного тестирования не обойтись. Часто используют инструменты типа JMeter, Gatling или Locust. Запуск таких тестов можно встроить в CI-пайплайн, но обычно их выполняют по расписанию или в отдельном окружении, так как требуется больше ресурсов и времени.

Пример сценария для JMeter (XML-файл) достаточно объёмный, поэтому покажу лишь фрагмент:

<TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Load Test Plan">

<hashTree>

<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group">

<stringProp name="ThreadGroup.num_threads">10</stringProp>

<stringProp name="ThreadGroup.ramp_time">5</stringProp>

<stringProp name="ThreadGroup.duration">60</stringProp>

...

</ThreadGroup>

<hashTree>

<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="GET /api/test"/>

...

</hashTree>

</hashTree>

</TestPlan>

Безопасностные тесты

Здесь можно упомянуть Snyk, SonarQube, OWASP ZAP. Они помогают искать уязвимости в коде, проверять зависимости, «пробовать» базовые атаки (SQL-инъекции, XSS и т.д.). Запуск таких проверок также желательно встраивать в CI. Например, SonarQube может анализировать код на предмет «code smells» и потенциальных уязвимостей.

Интеграция с конвейерами поставки кода

Ключ к успеху — правильно «связать» описанные инструменты и этапы тестирования в единую автоматизированную цепочку. При помощи Jenkinsfile, GitLab CI или GitHub Actions мы можем выстроить цепочку так, что после каждого пуша запускаются:

  1. Юнит-тесты

  2. Интеграционные тесты

  3. Статический анализ и линтинг

  4. При успехе — сборка и упаковка артефактов

  5. Загрузка артефактов (дистрибутивов, Docker-образов) в репозиторий

  6. Запуск нагрузочных тестов (по расписанию или по требованию)

  7. Развёртывание (staging, потом production)

Параллельно можно настроить уведомления (Slack, почта, Telegram) для быстрой реакции команды на фейлы.

Будущее развития и новые возможности

С каждым годом экосистема CI/CD становится всё более «умной» и автоматизированной:

  1. AI-асистенты. Уже появляются плагины и сервисы, которые анализируют логи тестов и предлагают, как исправить баг. Также AI может помогать оптимизировать пайплайны, подсказывая, какие тесты нужно запускать в первую очередь.

  2. «Shift-left» подход в безопасности. Всё больше инструментов направлено на то, чтобы безопасность учитывалась сразу при написании кода, а не в конце. Например, тот же GitHub CodeQL, позволяющий находить уязвимости на уровне анализатора кода.

  3. Контейнеризация и оркестрация. Docker и Kubernetes уже стали стандартом. Любой современный CI/CD-процесс старается использовать контейнеры для среды тестирования и деплоя. В будущем это будет только углубляться, появятся ещё более продвинутые инструменты оркестрации.

  4. Безсерверные пайплайны. Многие провайдеры предлагают Serverless-функции (AWS Lambda, Azure Functions), которые можно использовать для отдельных этапов конвейера. Это позволяет платить только за фактическое время выполнения и упростить управление инфраструктурой.

  5. Ускорение тестирования. Идёт тренд на умное кеширование и разделение тестов по важности. Часть тестов можно запускать при каждом коммите, а часть — периодически или только при мажорных изменениях.

Заключение

За десять лет работы я видел, как CI/CD из опционального элемента процесса разработки превратился в обязательную вещь. Сейчас без хороших автоматизированных конвейеров и тестирования проект быстро погружается в хаос: выходят баги, фичи задерживаются, команда тратит время на рутинные задачи.

Непрерывная интеграция и доставка позволяют команде сосредоточиться на разработке, креативе и решении реальных проблем пользователей, а не на монотонном процессе сборки и проверки. Современные инструменты дают возможность выстраивать сложные, но гибкие пайплайны. При этом не обязательно «изобретать велосипед» — можно брать готовые решения и адаптировать их под себя.

Главное — не бояться экспериментировать, постепенно внедрять новые уровни тестирования и учиться на ошибках. Тогда со временем вы придёте к такому процессу разработки, где выпускать фичи часто и без потери качества станет реальностью.

Комментарии (0)