Опишите структуру простого CI/CD пайплайна на примере GitHub Actions или GitLab CI

Ответ

CI/CD (Continuous Integration / Continuous Delivery) пайплайн — это автоматизированный процесс, который включает этапы сборки, тестирования и развертывания приложения при каждом изменении в коде.

Основные этапы простого пайплайна:

CI (Непрерывная интеграция):
- Checkout: Загрузка исходного кода из репозитория.
- Setup Environment: Настройка окружения (например, установка нужной версии Python, Node.js).
- Install Dependencies: Установка зависимостей проекта (pip install, npm install).
- Lint & Test: Запуск линтеров для проверки стиля кода и автоматических тестов для проверки логики.
CD (Непрерывная доставка/развертывание):
- Build: Сборка артефакта (например, Docker-образа).
- Deploy: Развертывание артефакта на сервере (staging или production).

Пример: GitHub Actions для Python-приложения (только CI-часть)

Файл .github/workflows/ci.yml:

name: Python CI

# Триггер для запуска: push в main или pull request в main
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest # Запуск на виртуальной машине с Ubuntu

    steps:
      # 1. Загрузка кода
      - name: Checkout repository
        uses: actions/checkout@v4

      # 2. Настройка Python
      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      # 3. Установка зависимостей
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      # 4. Запуск тестов
      - name: Run tests with pytest
        run: pytest

Пример: GitLab CI для того же приложения

Файл .gitlab-ci.yml:

# Определение стадий пайплайна
stages:
  - test
  - deploy

# Задача для стадии 'test'
test_job:
  stage: test
  image: python:3.10 # Использование Docker-образа с Python
  script:
    - echo "Installing dependencies..."
    - pip install -r requirements.txt
    - echo "Running tests..."
    - pytest

# Заглушка для стадии 'deploy'
deploy_job:
  stage: deploy
  script:
    - echo "Deploying application..."
    # Здесь будут команды для развертывания
  rules:
    - if: $CI_COMMIT_BRANCH == "main" # Выполнять только для ветки main

Ответ 18+ 🔞

А, вот и ты, наконец-то! Слушай, давай я тебе на пальцах, без этих заумных терминов, объясню, что за зверь такой — CI/CD пайплайн. Представь себе, что ты повар, а твой код — это борщ.

Вот как это работает, если по-человечьи:

CI (Непрерывная интеграция): Ты, сука, только что кинул в кастрюлю (репозиторий) свеклу (новый код).
- Checkout: Твой робот-помощник (пайплайн) прибегает и смотрит: «О, свекла! Беру!».
- Setup & Install: Он настраивает плиту (окружение), достаёт нужные кастрюли (зависимости) — лаврушку, перец, сметану.
- Lint & Test: А потом начинает орать: «А картошка-то не по ГОСТу нарезана! Линтер ругается!» И пробует ложкой: «Соль в норме? Тесты проходят? Не говно ли я, блядь, сварил?».
CD (Непрерывная доставка): Если борщ не вызвал рвотных позывов.
- Build: Робот аккуратно разливает этот проверенный борщ по стерильным контейнерам (собирает артефакт или Docker-образ).
- Deploy: И несёт эти контейнеры прямиком на стол к голодным клиентам (на сервер), минуя твои кривые руки. Всё, блядь, автоматически! Ты даже пальцем не пошевелил!

И так КАЖДЫЙ РАЗ, когда ты туда какую-то хуйню подбрасываешь. Красота, да? Никакого «ой, а у меня на машине работало».

Смотри, как это выглядит в жизни, на примере GitHub Actions (только проверочная часть):

Файлик .github/workflows/ci.yml:

name: Python CI

# Когда это всё стартанёт: когда ты впихнул код в main или пытаешься его туда впихнуть
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest # Всё это будет крутиться на свеженькой убунту в облаке

    steps:
      # 1. Робот пришёл и скопировал твой код
      - name: Checkout repository
        uses: actions/checkout@v4

      # 2. Робот поставил нужный Python, ёпта
      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      # 3. Робот ставит все твои кривые зависимости
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      # 4. Робот запускает тесты. Вот тут-то и вылезает вся правда.
      - name: Run tests with pytest
        run: pytest

А вот так почти то же самое, но на GitLab CI:

Файлик .gitlab-ci.yml:

# Определяем этапы конвейера. Сначала проверим, потом, если живы, выкатим.
stages:
  - test
  - deploy

# Задача для этапа 'test'
test_job:
  stage: test
  image: python:3.10 # Всё делаем внутри готового образа с питоном
  script:
    - echo "Ставлю зависимости... Надеюсь, они не сломают всё к ебеням."
    - pip install -r requirements.txt
    - echo "Запускаю тесты... Волнение ебать."
    - pytest

# Заглушка для этапа 'deploy'. Тут уже магия развёртывания.
deploy_job:
  stage: deploy
  script:
    - echo "Выкатываю приложение на сервак... Пиздец, страшно."
    # Здесь были бы настоящие команды, но это уже другая история
  rules:
    - if: $CI_COMMIT_BRANCH == "main" # И только если всё залили в главную ветку

Вот и вся магия, друг. Сначала автоматически проверяем, не насрали ли мы в код, а потом, если всё чисто, так же автоматически отправляем это добро людям. И спать спокойно. Ну, почти.