CI/CD в реальном секторе: как мы ускоряем разработку и внедрение у клиентов

Современная ИТ-инфраструктура требует скорости обновлений без ущерба для стабильности. Рассказываем, как мы внедряем практики CI/CD для клиентов Mac-Key: от автоматизации сборки 1С до деплоя веб-сервисов и обновлений через Ansible.

Когда говорят о CI/CD, многие представляют себе стартапы, которые деплоят код на Kubernetes десятки раз в день. Но практики непрерывной интеграции и доставки не менее важны для компаний из реального сектора — там, где работают с 1С, корпоративными порталами и внутренними сервисами.

В Mac-Key мы адаптируем принципы CI/CD под задачи наших клиентов, помогая им обновлять ПО быстрее, безопаснее и с минимальными простоями.

Что такое CI/CD и зачем это бизнесу

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

CD (Continuous Delivery/Deployment) — автоматическая доставка проверенных изменений до продуктивного окружения.

Для бизнеса это означает:

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

Где мы применяем CI/CD у клиентов

1. Автоматизация обновлений 1С

Обновление конфигураций 1С — процесс, который вручную может занимать часы и требует полной остановки работы пользователей. Мы автоматизируем его с помощью сценариев, которые:

Создают резервную копию базы перед обновлением
Загружают новую конфигурацию из репозитория
Выполняют обновление в нерабочее время
Проверяют целостность базы и запускают регламентные операции
Отправляют отчёт о результате в корпоративный мессенджер

2. Деплой веб-сервисов и микросервисов

Для клиентов, которые разрабатывают собственные веб-приложения или используют кастомные сервисы, мы выстраиваем пайплайны на базе GitLab CI/CD или Jenkins. Типовой сценарий:

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - docker run --rm -v $(pwd):/app python:3.11 pytest /app/tests

build:
  stage: build
  script:
    - docker build -t registry.mac-key.ru/client-app:$CI_COMMIT_SHA .
    - docker push registry.mac-key.ru/client-app:$CI_COMMIT_SHA

deploy:
  stage: deploy
  script:
    - ansible-playbook -i inventory/production deploy.yml
  only:
    - main

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

Инструменты, которые мы используем

Инструмент	Для чего
GitLab CI/CD	Основной оркестратор пайплайнов, хранение кода, реестр образов
Jenkins	Для legacy-проектов или сложных кастомных сценариев
Ansible	Управление конфигурациями, деплой, оркестрация
Docker / Podman	Контейнеризация приложений для изоляции и переносимости
Harbor	Приватный реестр Docker-образов (размещается в инфраструктуре Mac-Key)

Безопасность в CI/CD

Автоматизация не должна создавать новых дыр в безопасности. Мы следуем ключевым принципам:

Изоляция секретов: пароли, токены и SSH-ключи никогда не хранятся в коде. Они передаются через защищённые переменные CI/CD-систем.
Принцип наименьших привилегий: сервисные учётные записи для деплоя имеют ровно те права, которые нужны для выполнения задачи.
Обязательное ревью: изменения в основную ветку попадают только через Merge Request с обязательной проверкой.
Иммутабельные артефакты: Docker-образы, прошедшие тесты, не пересобираются перед деплоем на продуктив. В production уходит тот же самый артефакт, что был протестирован.

Кейс: внедрение CI/CD для веб-портала клиента

Проблема: клиент разрабатывает внутренний портал для сотрудников. Разработчики вручную выкладывают обновления через FTP. Часто возникают ошибки из-за несовпадения версий PHP или отсутствующих расширений. Откат к предыдущей версии — головная боль.

Что мы сделали:

Перенесли код в GitLab с настроенным CI/CD
Написали Dockerfile, который гарантирует идентичное окружение на тесте и продуктиве
Настроили пайплайн: push в ветку dev → автотесты → деплой на тестовый стенд
Merge request в main → ручное подтверждение → деплой на продуктив через Ansible
Внедрили автоматический откат (rollback) в случае неудачного деплоя

Результат:

Время выкладки новой версии сократилось с 40 минут до 3 минут
Количество ошибок, связанных с окружением, снизилось до нуля
Разработчики перестали тратить время на ручной деплой и сосредоточились на коде

Коротко

CI/CD — это не только для стартапов. Это практика, которая делает ИТ-инфраструктуру управляемой, обновления — быстрыми, а откаты — безболезненными.

Хотите узнать, как CI/CD может ускорить разработку в вашей компании? Запросите аудит — мы проанализируем текущие процессы и предложим roadmap автоматизации.