Развертывание приложений с GitLab CI/CD: Руководство для разработчиков

GitLab CI/CD является одним из самых гибких инструментов для автоматизации процессов непрерывной интеграции (CI) и непрерывного развертывания (CD) в мире разработки программного обеспечения. Этот инструмент позволяет разработчикам автоматически тестировать и развертывать их код в различных средах, обеспечивая более высокое качество продукции и ускорение процесса разработки.

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

Преимущества использования:

1. Автоматизация процессов: GitLab CI/CD автоматизирует процессы сборки, тестирования и развертывания, что значительно сокращает время на разработку и выпуск новых версий продукта.
2. Улучшение качества кода: Непрерывное тестирование кода помогает обнаруживать и исправлять ошибки на ранних этапах, что ведет к улучшению общего качества продукта.
3. Быстрый feedback: Разработчики быстро получают обратную связь о качестве кода и совместимости изменений, что позволяет оперативно вносить необходимые коррективы.
4. Гибкость и масштабируемость: GitLab CI/CD поддерживает различные среды и конфигурации, предоставляя гибкие настройки для масштабирования проектов.
5. Уменьшение рисков: Автоматизированное развертывание в различные среды с использованием стратегий, таких как canary deployments и blue-green deployment, помогает минимизировать риски при выходе новых версий.
6. Экономия ресурсов: Минимизация ручных операций не только сокращает время на разработку и деплой, но и экономит ресурсы команды, позволяя разработчикам сосредоточиться на задачах высокого приоритета.

В совокупности эти преимущества делают GitLab CI/CD неотъемлемым инструментом для команд разработчиков, стремящихся к эффективности, безопасности и качеству в процессе разработки программного обеспечения.

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

Для включения и настройки GitLab Runner на вашем сервере или локальном компьютере с Linux, следуйте следующему процессу. Это позволит вашим проектам в GitLab использовать непрерывную интеграцию (CI/CD) для автоматизации процессов тестирования, сборки и развертывания вашего кода.

Шаг 1: Установка GitLab Runner (пример на Ubuntu)

• Добавление репозитория GitLab Runner: Это обеспечит доступ к последним версиям и обновлениям.

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

Команда скачивает и выполняет скрипт, который добавляет репозиторий GitLab Runner к вашему списку источников программного обеспечения, позволяя установить и обновлять GitLab Runner через системный менеджер пакетов.

• Установка GitLab Runner: После добавления репозитория установите GitLab Runner, используя apt-get.

sudo apt-get install gitlab-runner

Шаг 2: Регистрация GitLab Runner

• Получение данных: Для работы Runner его нужно связать с проектом в GitLab. Для этого заходим на страницу проекта и в меню слева выбираем -> Settings -> CI / CD:

Выбираем ОС и копируем нижнюю строку для регистрации Runner

• Запуск процесса регистрации: Запустите процесс регистрации, используя команду:

sudo gitlab-runner register --url https://gitlab.com/ --registration-token GR134...

Вам будет предложено ввести несколько значений для настройки раннера:

• GitLab instance URL: URL вашего GitLab сервера. В нашем случае просто enter, так как он прописан как параметр.
• Registration token: Токен для регистрации, который связывает Runner с конкретным проектом или группой. Тоже прописан параметром, если была скопирована строка в GitLab.
• Description: Описание Runner'а, помогает идентифицировать его среди других Runner'ов.
• Tags: Теги для Runner'а, определяющие, для каких задач он может быть использован.
• Optional maintenance note: Примечание, которое может содержать информацию о техобслуживании или другие заметки о Runner'е.
• Выбор исполнителя: Затем выберите исполнителя (executor), который определяет среду, в которой будут выполняться задачи.

Исполнители (executors):

1. SSH
   • Использование: Подключается к удаленным серверам через SSH для выполнения задач.
   • Цели применения: Идеально подходит для сценариев, когда у вас уже есть выделенные серверы для CI/CD, и вы хотите использовать их без установки дополнительного программного обеспечения.
2. Parallels
   • Использование: Запускает задачи в изолированных виртуальных машинах на macOS с использованием Parallels Desktop.
   • Цели применения: Подходит для сборки и тестирования приложений iOS и macOS в среде macOS.
3. Docker
   • Использование: Выполняет задачи в Docker контейнерах.
   • Цели применения: Обеспечивает изоляцию и воспроизводимость среды, идеально подходит для большинства проектов CI/CD.
4. Docker+Machine
   • Использование: Автоматически создает и удаляет виртуальные машины Docker с использованием Docker Machine. Это динамическое создание и удаление помогает оптимизировать использование ресурсов.
   • Цели применения: Подходит для эластичного масштабирования CI/CD пайплайнов.
5. Kubernetes
   • Использование: Запускает задачи в контейнерах внутри кластера Kubernetes.
   • Цели применения: Идеально для проектов, использующих Kubernetes, позволяет легко масштабировать и управлять зависимостями.
6. VirtualBox
   • Использование: Запускает задачи в виртуальных машинах VirtualBox.
   • Цели применения: Подходит для сценариев, требующих полной виртуализации для тестирования в различных средах.
7. Custom
   • Использование: Позволяет определить собственную логику запуска задач с использованием пользовательского скрипта.
   • Цели применения: Для сложных сценариев и окружений, которые не поддерживаются другими исполнителями напрямую.
8. Shell
   • Использование: Выполняет задачи непосредственно на машине, где запущен Runner.
   • Цели применения: Простая настройка для небольших проектов или когда не требуется изоляция среды.
9. Docker-Windows
   • Использование: Аналогично Docker, но для Windows контейнеров.
   • Цели применения: Для сборки и тестирования приложений, специфичных для Windows.
10. Docker-Autoscaler
    • Использование: Автоматически масштабирует количество Runner'ов в зависимости от нагрузки, используя Docker.
    • Цели применения: Для проектов с переменной нагрузкой, где требуется оптимизация ресурсов.
11. Instance
    • Использование: Похож на Shell, но с дополнительными возможностями безопасности и изоляции.
    • Цели применения: Для сред, требующих повышенной безопасности или изоляции.

После ввода всех необходимых данных ваш Runner будет зарегистрирован в GitLab и готов к использованию. Теперь вы можете настроить ваш .gitlab-ci.yml файл в проектах, чтобы использовать этот Runner для выполнения задач CI/CD.

Файл .gitlab-ci.yml является ключевым элементом в экосистеме GitLab CI/CD, определяя, как должны выполняться автоматизированные задачи по тестированию, сборке и развертыванию вашего проекта. Файл использует YAML (YAML Ain't Markup Language) — человекочитаемый формат данных для конфигурации пайплайнов. Понимание структуры и синтаксиса этого файла позволит вам эффективно настраивать процессы CI/CD для ваших проектов.

Файл .gitlab-ci.yml включает в себя несколько ключевых секций, каждая из которых выполняет определенную роль в процессе CI/CD:

• stages: Определяет этапы пайплайна, которые выполняются последовательно. Эти этапы помогают организовать задачи (jobs) в логические группы, например, build, test, deploy.
• job: Самая основная единица пайплайна, представляющая инструкции, которые выполняются. Каждая задача принадлежит к определенному этапу. Задачи в одном и том же этапе запускаются параллельно, если только не указано иначе.
• script: Команды, которые выполняются в рамках задачи. Это может быть компиляция кода, выполнение тестов или развертывание.
• before_script и after_script: Команды, которые выполняются до или после script соответственно, в рамках каждой задачи. Они могут быть использованы для настройки среды или очистки после выполнения задачи.
• variables: Определяет переменные окружения, доступные во всех задачах пайплайна.
• include: Позволяет включать внешние YAML-файлы для повторного использования конфигураций, что упрощает управление большими и сложными пайплайнами.
• artifacts: Определяет файлы и директории, созданные задачей, которые следует сохранить после выполнения задачи для использования в последующих задачах или этапах.
• cache: Позволяет кэшировать зависимости и директории между выполнениями задач, что ускоряет сборку и тестирование.

Это только основы структуры файла .gitlab-ci.yml. GitLab CI/CD предоставляет гораздо больше возможностей и настроек, позволяя вам создавать сложные пайплайны, точно настроенные под нужды вашего проекта. Важно понимать эти основы, чтобы начать работу с GitLab CI/CD, и постепенно углублять свои знания, изучая дополнительные возможности и лучшие практики.

В файле конфигурации .gitlab-ci.yml GitLab CI/CD используется ряд ключевых элементов синтаксиса, позволяющих настроить поведение пайплайнов. Подробнее рассмотрим основные элементы.

workflow: Контроль запуска пайплайнов

workflow позволяет управлять запуском пайплайнов на основе заданных условий. Это может быть полезно для предотвращения запуска пайплайнов в ненужные моменты, например, когда изменения вносятся только в определенные файлы или каталоги, или в зависимости от переменных среды или веток. Это может помочь сократить количество ненужных запусков пайплайнов, экономя ресурсы и время.

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
    - changes:
        - path/to/directory/**
        - "*.config"

В этом примере пайплайн будет запущен, если выполнено одно из следующих условий: коммит сделан в ветку main, пайплайн запущен по расписанию, или были изменены файлы в указанной директории или файлы конфигурации на верхнем уровне.

stages: Определение этапов пайплайна

Элемент stages используется для определения различных этапов пайплайна, которые выполняются последовательно. Этапы позволяют группировать задачи (jobs), которые могут выполняться параллельно в пределах одного этапа, но сам этап будет ожидать завершения всех задач, прежде чем перейти к следующему.

stages:
  - build
  - test
  - deploy

В этом примере определены три этапа: build, test и deploy. Задачи, относящиеся к сборке проекта, будут группироваться в этап build, задачи тестирования — в test, а задачи развертывания — в deploy.

include: Повторное использование конфигураций

include позволяет включить в текущий .gitlab-ci.yml внешние YAML-файлы. Это полезно для повторного использования общих конфигураций в нескольких проектах или для разделения большого файла конфигурации на более мелкие и управляемые части.

include:
  - project: 'my-group/my-project'
    ref: master
    file: '/templates/.template.yml'
  
  - local: '/ci/common.yml'

Здесь конфигурация включает файл из другого проекта (my-group/my-project) и локальный файл (/ci/common.yml). Это позволяет легко переиспользовать настройки CI/CD между разными проектами и упрощает управление конфигурацией.

variables: Определение и использование переменных

В секции variables можно определить переменные окружения, которые будут доступны во всех задачах пайплайна. Эти переменные можно использовать для конфигурации поведения задач, без необходимости жестко кодировать конфигурационные значения прямо в файле .gitlab-ci.yml.

variables:
  PROJECT_ENV: "production"
  DEPLOY_PATH: "/var/www/html"

В этом примере определены две переменные: PROJECT_ENV и DEPLOY_PATH, которые затем могут быть использованы в скриптах задач для определения среды проекта и пути развертывания соответственно.

Использование этих элементов синтаксиса .gitlab-ci.yml позволяет создавать конфигурации пайплайнов, которые могут быть адаптированы к различным потребностям проекта, упрощая процесс разработки и обеспечивая эффективность и надежность процессов CI/CD.

before_script и after_script: Предварительные и завершающие скрипты

before_script:

Секция before_script используется для определения команд или скриптов, которые должны быть выполнены перед каждой задачей (job) в пайплайне. Это полезно для выполнения общих подготовительных шагов, таких как установка зависимостей, авторизация в сервисах или настройка окружения.

before_script:
  - echo "Выполнение предварительных скриптов..."
  - setup-environment.sh

В этом примере перед каждой задачей будут выполнены команды для вывода сообщения в лог и запуска скрипта setup-environment.sh.

after_script:

Секция after_script определяет команды или скрипты, которые выполняются после каждой задачи, независимо от её исхода (успех или неудача). Это можно использовать для очистки ресурсов, логирования информации или отправки уведомлений.

after_script:
  - echo "Завершающие действия..."
  - cleanup-environment.sh

Здесь после завершения каждой задачи будут выполнены команды для вывода сообщения и запуска скрипта cleanup-environment.sh для очистки окружения.

tags: Назначение Runner на основе тегов

tags в GitLab CI/CD используются для назначения задач конкретным Runner'ам на основе тегов. Это позволяет контролировать, на каких Runner'ах будут выполняться определенные задачи, основываясь на их спецификации, такой как тип операционной системы, доступные ресурсы или специализированное оборудование.

build-job:
  stage: build
  script:
    - build-project.sh
  tags:
    - linux
    - docker

В этом примере задача build-job будет направлена на выполнение только на тех Runner'ах, которые помечены тегами linux и docker. Это обеспечивает, что задача сборки проекта будет выполняться в среде, подходящей для сборки Linux-проектов, использующих Docker.

Использование before_script, after_script и tags позволяет более тонко управлять процессом выполнения пайплайна, адаптируя его под конкретные требования и ограничения проекта. 

Jobs (задачи) являются основными строительными блоками пайплайнов в GitLab CI/CD. Каждая задача определяет набор операций, которые должны быть выполнены: это может быть сборка кода, выполнение тестов, развертывание приложения и т.д.

Ключевой элемент каждой задачи — script, который содержит команды или скрипты, выполняемые в рамках задачи.

test-job:
  stage: test
  script:
    - echo "Запуск тестов..."
    - run-tests.sh

В этом примере задача test-job находится на этапе test и выполняет две команды: вывод сообщения и запуск скрипта run-tests.sh.

only и except — это директивы, позволяющие контролировать, когда задача должна выполняться, основываясь на различных условиях, таких как ветки, теги или переменные среды.

• only определяет условия, при которых задача будет выполняться. Если условия совпадают, задача включается в пайплайн.

deploy-job:
  stage: deploy
  script:
    - deploy-application.sh
  only:
    - master
    - tags

Здесь deploy-job будет выполняться только если изменения сделаны в ветке master или если был установлен тег.

• except указывает условия, при которых задача не будет выполняться. Если условия совпадают, задача исключается из пайплайна.

experimental-test-job:
  stage: test
  script:
    - experimental-tests.sh
  except:
    - master

В этом примере experimental-test-job будет исключена из выполнения, если изменения сделаны в ветке master.

Использование only и except позволяет динамично управлять составом задач в пайплайне, адаптируя процесс CI/CD под различные сценарии разработки и доставки. Это включает в себя возможность создания отдельных пайплайнов для работы с фича-ветками, автоматическое развертывание только для определенных тегов или исключение некоторых задач на определенных этапах разработки.

Конфигурация этапов (stages) в GitLab CI/CD играет важную роль в организации и управлении жизненным циклом разработки программного обеспечения. Она позволяет разработчикам структурировать пайплайн развертывания таким образом, чтобы различные задачи (jobs), такие как сборка (build), тестирование (test) и развертывание (deploy), выполнялись в определенном, логически обоснованном порядке. Этот подход не только обеспечивает четкое разделение ответственности между различными этапами разработки, но и повышает эффективность и надежность процессов CI/CD.

В .gitlab-ci.yml, порядок, в котором этапы перечислены в секции stages, непосредственно определяет последовательность их выполнения в пайплайне. Эти этапы организуются таким образом, чтобы каждый последующий этап начинался только после полного и успешного завершения всех задач предыдущего этапа. Это гарантирует, что все необходимые предварительные условия и зависимости удовлетворены перед переходом к следующему шагу.

stages:
  - build
  - test
  - deploy

GitLab CI/CD предоставляет два механизма для управления зависимостями между задачами: dependencies и needs:

• dependencies: Этот ключ позволяет задаче наследовать и использовать артефакты, сгенерированные предыдущими задачами. Это означает, что задача может оперировать результатами работы других задач, но её выполнение будет отложено до полного завершения всех задач текущего этапа. Это обеспечивает строгую последовательность выполнения, но может привести к ненужным задержкам.

test1:
  stage: test
  dependencies:
    - compile

• needs: В отличие от dependencies, директива needs позволяет задаче начать выполнение немедленно после завершения указанных зависимостей, не ожидая окончания всех задач на текущем этапе. Это способствует параллельному выполнению и может значительно сократить общее время выполнения пайплайна, ускоряя процесс CI/CD.

test2:
  stage: test
  needs:
    - compile

Одной из основных преимуществ структурирования пайплайнов с использованием stages является возможность параллельного выполнения задач внутри одного этапа. Это позволяет оптимизировать использование ресурсов и сократить общее время выполнения пайплайна. GitLab автоматически запускает все задачи одного этапа параллельно, если только не ограничено зависимостями (dependencies) или потребностями (needs).

stages:
  - build
  - test
  - deploy

build_job_1:
  stage: build
  script:
    - echo "Building part 1..."

build_job_2:
  stage: build
  script:
    - echo "Building part 2..."

GitLab CI/CD позволяет автоматизировать процессы очистки с помощью директивы on_stop в определении окружения, где environment позволяет определить окружение, в котором выполняется задача. Это может быть любая среда, например, тестовая, стейджинг или продуктовая. Каждое окружение может иметь свою уникальную конфигурацию и жизненный цикл. Директива on_stop в определении environment используется для указания задачи, которая должна быть выполнена для остановки или удаления этого окружения. Это особенно полезно для временных окружений, создаваемых для ревью кода или тестирования, которые необходимо очистить после использования.

stop_review:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Removing review environment..."
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  only:
    - branches
  except:
    - main

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

test:
  stage: test
  services:
    - postgres:latest
  script:
    - echo "Testing with PostgreSQL..."

Конфигурация stages в GitLab CI/CD представляет собой инструмент для организации и управления пайплайнами непрерывной интеграции и доставки. Благодаря гибкости настройки этапов, зависимостей и условий выполнения задач, разработчики могут создавать сложные пайплайны, оптимизированные под конкретные потребности проекта, что способствует ускорению процессов разработки и обеспечению высокого качества продукта.

Переменные в GitLab CI/CD предоставляют механизм для динамической настройки пайплайнов. Они могут быть использованы для конфигурации задач на лету, позволяя задавать различные параметры без необходимости изменения самого файла .gitlab-ci.yml. Переменные могут быть определены на уровне GitLab CI/CD пайплайна в файле .gitlab-ci.yml, на уровне проекта или группы в настройках GitLab, а также могут быть предоставлены как переменные среды в Runner.

Переменные могут быть использованы для разнообразных целей в пайплайне, включая:

• Конфигурацию задач: определение специфических параметров, необходимых для выполнения скриптов сборки, тестирования и развертывания.
• Управление средами: указание среды, в которую будет производиться развертывание, или настройка параметров, специфичных для среды.
• Передачу секретов: безопасное предоставление чувствительной информации, такой как пароли, токены доступа или ключи API, без их явного указания в файле .gitlab-ci.yml.

deploy:
  stage: deploy
  script:
    - deploy-to-env.sh $DEPLOY_ENV
  variables:
    DEPLOY_ENV: staging

В этом примере переменная DEPLOY_ENV используется для определения среды развертывания в задаче deploy. Значение staging указано напрямую в конфигурации задачи, однако оно может быть легко изменено или переопределено на уровне проекта или группы через настройки GitLab, а также может быть задано динамически через переменные среды в Runner.

Переменные в GitLab CI/CD могут быть определены на нескольких уровнях:

• Файл .gitlab-ci.yml: Непосредственное определение переменных в конфигурации пайплайна позволяет задать стандартные значения или специфичные настройки для задач.
• Настройки проекта или группы: Переменные, заданные на уровне проекта или группы в GitLab, автоматически применяются ко всем пайплайнам в рамках этого проекта или группы. Это удобно для глобальных настроек или секретов.
• Переменные среды Runner: Эти переменные могут быть заданы на уровне Runner и являются полезными для конфигурации окружения, в котором выполняются задачи.

Одной из ключевых особенностей переменных в GitLab CI/CD является возможность их переопределения на разных уровнях. Это позволяет, например, задать значение переменной по умолчанию в файле .gitlab-ci.yml, но при необходимости изменить его на уровне проекта для конкретного запуска пайплайна или даже передать другое значение через переменные среды Runner, обеспечивая тем самым высокую степень гибкости и адаптации к различным условиям выполнения задач.

Артефакты — это файлы и директории, генерируемые в результате выполнения задач в пайплайне. Они используются для сохранения важных результатов работы, таких как результаты сборки, тестовые отчеты, логи, или любые другие данные, которые необходимо сохранить после завершения задачи. Артефакты могут быть переданы между задачами в рамках одного пайплайна или сохранены для доступа после его завершения.

test:
  stage: test
  script:
    - run-tests.sh
  artifacts:
    paths:
      - test-results/
    expire_in: 2 days
    when: always

В приведенном примере задача test генерирует артефакты в директории test-results, которые сохраняются на срок до 2 дней. Опция when: always гарантирует сохранение артефактов независимо от результата выполнения задачи.

Кэширование, с другой стороны, предназначено для временного хранения файлов и директорий, которые используются между различными запусками задач. Это особенно актуально для зависимостей проекта, позволяя не загружать их каждый раз, когда выполняется пайплайн. Кэширование сокращает время на сборку и тестирование, оптимизируя использование ресурсов.

build:
  stage: build
  script:
    - npm install
  cache:
    paths:
      - node_modules/
    key: ${CI_COMMIT_REF_SLUG}

В данном примере:

paths: указывает директории или файлы, которые необходимо кэшировать. В этом случае кэшируется директория node_modules, где npm сохраняет зависимости проекта.

key: определяет ключ кэша, который используется для ассоциации кэша с конкретными задачами и условиями. В примере ключ кэша задается как ${CI_COMMIT_REF_SLUG}, что означает использование уникального идентификатора ветки в качестве ключа. Это позволяет каждой ветке иметь свой собственный кэш, предотвращая конфликты и некорректное использование зависимостей между различными ветками.

GitLab CI/CD предоставляет различные стратегии управления кэшем, такие как:

• policy: pull: кэш будет только загружаться, но не обновляться в результате выполнения задачи.
• policy: push: кэш будет обновляться после выполнения задачи, но не загружаться при ее старте.
• policy: pull-push (по умолчанию): кэш будет загружаться перед выполнением задачи и обновляться после ее завершения.

Преимущества кэширования:

• Уменьшение времени сборки: за счет повторного использования уже скачанных или сгенерированных данных.
• Экономия ресурсов: уменьшает нагрузку на сеть и серверы хранения, поскольку уменьшается количество необходимых загрузок из внешних источников.
• Гибкость конфигурации: ключи кэша и стратегии позволяют настроить кэширование с учетом специфики проекта и рабочих процессов.

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

Этот пример демонстрирует, как настроить GitLab CI/CD пайплайн для сборки и развертывания веб-приложения на Django, используя Redis и Postgres в качестве сервисов и Pytest для тестирования.

• Определение этапов пайплайна:

stages:
  - build
  - test
  - deploy

• Сборка приложения:

На этапе сборки устанавливаются зависимости, необходимые для приложения.

build-app:
  stage: build
  image: python:3.8
  script:
    - pip install -r requirements.txt
  artifacts:
    paths:
      - ./
    expire_in: 1 hour
  only:
    - master

• Тестирование приложения:

На этапе тестирования запускаются тесты с использованием Pytest, а также могут быть задействованы сервисы, такие как Postgres и Redis.

test-app:
  stage: test
  image: python:3.8
  services:
    - postgres:latest
    - redis:latest
  variables:
    POSTGRES_DB: test_db
    POSTGRES_USER: user
    POSTGRES_PASSWORD: password
  script:
    - pytest
  dependencies:
    - build-app
  only:
    - master

На этапе развертывания приложение разворачивается на целевом сервере. Здесь предполагается, что вы используете внешний сервер и имеете доступ к нему по SSH.

deploy-app:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --update openssh-client
    - ssh user@yourserver.com 'cd /path/to/your/app && git pull && docker-compose up -d'
  only:
    - master
  when: manual

В этом примере:

• На этапе сборки (build-app) происходит установка всех зависимостей из файла requirements.txt. Результаты сборки сохраняются как артефакты на один час.
• На этапе тестирования (test-app) запускаются тесты с помощью Pytest. Для тестов используются контейнеры Postgres и Redis, настроенные как сервисы. Переменные окружения для Postgres задаются непосредственно в определении задачи.
• На этапе развертывания (deploy-app) используется образ Alpine для минимизации размера и устанавливаются необходимые инструменты (в данном случае, openssh-client). Сценарий развертывания предполагает доступ к серверу по SSH, где выполняются команды для обновления исходного кода и перезапуска контейнеров через docker-compose.

Этот пример представляет базовую настройку пайплайна для веб-приложения на Django с использованием Redis и Postgres, а также демонстрирует, как можно настроить среду для тестирования и развертывания приложения. В реальных проектах конфигурация может варьироваться в зависимости от требований к проекту, инфраструктуре и используемым технологиям.