Codebase — одна кодовая база — 12-Factor App:

Codebase: Одна кодовая база

Одна кодовая база в системе контроля версий, множество развёртываний

#Суть принципа

Codebase — это фундамент 12-Factor методологии. Принцип гласит:

Существует ровно одна кодовая база приложения в системе контроля версий (Git). Из этой кодовой базы развёртываются все окружения: development, staging, production.

✅ Правильно:
┌─────────────────┐
│   Git Repo      │
│   (one codebase)│
└────────┬────────┘
         │
    ┌────┴────┬────────────┐
    ▼         ▼            ▼
┌───────┐ ┌───────┐  ┌──────────┐
│  Dev  │ │Staging│  │Production│
└───────┘ └───────┘  └──────────┘

#Почему одна кодовая база?

#Проблема: разные репозитории для разных сред

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

❌ Неправильно:
myapp-dev/     ← разработка здесь
myapp-staging/ ← тестирование здесь
myapp-prod/    ← production здесь (доступ только у сеньоров)

Проблемы такого подхода:

Дрейф кода — код в разных репозиториях расходится
Сложное слияние — фиксы из prod нужно вручную переносить в dev
Ошибки развёртывания — легко забыть перенести критический фикс
Непонятная история — кто, когда и зачем изменил код в prod-репозитории?

#Решение: один репозиторий, разные конфигурации

✅ Правильно:
myapp/  ← единый репозиторий
├── src/
├── tests/
├── requirements.txt
└── .github/workflows/ci.yml

Развёртывания:
- Dev:      git checkout main && DEPLOY_ENV=dev ./deploy.sh
- Staging:  git checkout main && DEPLOY_ENV=staging ./deploy.sh
- Prod:     git checkout main && DEPLOY_ENV=prod ./deploy.sh

Преимущества:

✅ Всегда известно, какой код где работает
✅ Фиксы автоматически попадают во все среды
✅ Прозрачная история изменений
✅ Любой разработчик может развернуть любую среду

#Что такое «кодовая база» в современном понимании

#Монолитная кодовая база

Одно приложение — один репозиторий:

myapp/
├── src/
├── tests/
├── requirements.txt
└── README.md

#Микросервисы: один репозиторий на сервис

Каждый микросервис — отдельная кодовая база:

user-service/     ← кодовая база сервиса пользователей
order-service/    ← кодовая база сервиса заказов
payment-service/  ← кодовая база сервиса платежей

Важно: у каждого сервиса своя независимая история версий и развёртываний.

#Monorepo: несколько сервисов в одном репозитории

company-apps/  ← единый репозиторий
├── user-service/
├── order-service/
├── payment-service/
└── shared-libs/

Это всё ещё соответствует 12-Factor, если:

Каждый сервис развёртывается независимо
У каждого сервиса своя история релизов
Изменение одного сервиса не требует изменения других

#Множество развёртываний

Из одной кодовой базы развёртываются разные окружения:

#Типичные окружения

Окружение	Назначение	Конфигурация
Development	Локальная разработка	Локальная БД, debug-режим
Staging	Тестирование перед prod	Копия prod-данных, debug-режим
Production	Работа с реальными пользователями	Production-БД, debug отключён
CI/CD	Автоматические тесты	Временная БД, изолированное окружение

#Как это работает на практике

# Один и тот же код, разные переменные окружения
git checkout main

# Развёртывание в dev
export DEPLOY_ENV=dev
export DATABASE_URL=postgres://localhost:5432/dev_db
export DEBUG=true
./deploy.sh

# Развёртывание в prod
export DEPLOY_ENV=prod
export DATABASE_URL=postgres://prod-db:5432/prod_db
export DEBUG=false
./deploy.sh

Код не меняется — меняется только конфигурация.

#Ветвление и релизы

#Git Flow для 12-Factor

main (prod)
  │
  ├─── release/v2.1 ───────► staging
  │
  ├─── feature/new-payment
  │
  └─── hotfix/critical-bug

Процесс:

Разработка в feature-ветках
Слияние в main после code review
Развёртывание main в staging
Тестирование на staging
Развёртывание main в production

#Теги для версионирования

# Пометить релиз тегом
git tag -a v2.1.0 -m "Release version 2.1.0"
git push origin v2.1.0

# Развернуть конкретную версию
git checkout v2.1.0
./deploy.sh --env=prod

#Антипаттерны Codebase

#❌ FTP-развёртывание

# Ручное копирование файлов на сервер
scp app.py user@server:/var/www/
scp -r templates/ user@server:/var/www/templates/
ssh user@server "service apache restart"

Проблемы:

Нет истории изменений на сервере
Невозможно откатиться к предыдущей версии
Ручная работа подвержена ошибкам

#❌ Разные ветки для разных сред

# Неправильно: отдельные ветки для каждой среды
git checkout prod
# Код сильно отличается от main
# Фиксы из main не попадают в prod

git checkout staging
# Ещё одна версия кода

Проблемы:

Ветки расходятся со временем
Слияние становится болезненным
Непонятно, где «истина»

#❌ Конфигурация в коде

# ❌ Неправильно: разные значения для разных сред в коде
if ENV == 'prod':
    DATABASE_URL = 'postgres://prod-db/app'
elif ENV == 'staging':
    DATABASE_URL = 'postgres://staging-db/app'
else:
    DATABASE_URL = 'postgres://localhost/app'

Правильно: конфигурация передаётся извне через переменные окружения.

#Практические рекомендации

#1. Используйте Git

# Инициализация репозитория
git init
git add .
git commit -m "Initial commit"

# Удалённый репозиторий
git remote add origin git@github.com:company/myapp.git
git push -u origin main

#2. Настройте CI/CD

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Deploy to staging
        run: ./deploy.sh staging
      
      - name: Run tests
        run: pytest
      
      - name: Deploy to production
        run: ./deploy.sh production

#3. Защищённые ветки

Настройте защиту ветки main:

Запрет прямого push в main
Обязательный code review перед слиянием
Обязательное прохождение CI-тестов

#4. Версионирование релизов

# Семантическое версионирование
git tag -a v2.1.0 -m "Release 2.1.0: new payment system"
git push origin v2.1.0

# Автоматическое создание релиза в GitHub/GitLab

#5. Откат к предыдущей версии

# Быстрый откат через git
git revert HEAD  # Отмена последнего коммита
git push

# Или развёртывание предыдущего тега
git checkout v2.0.0
./deploy.sh --env=prod

#Codebase в микросервисной архитектуре

#Независимые репозитории

# Каждый сервис — отдельная кодовая база
github.com/company/user-service
github.com/company/order-service
github.com/company/payment-service

Преимущества:

Полная независимость развёртывания
Разные команды работают автономно
Разные технологии для разных сервисов

#Monorepo подход

# Все сервисы в одном репозитории
github.com/company/platform
├── services/
│   ├── user/
│   ├── order/
│   └── payment/
└── libs/
    ├── auth/
    └── logging/

Преимущества:

Общие библиотеки без дублирования
Атомарные изменения across сервисов
Единая CI/CD инфраструктура

#Инструменты

Задача	Инструменты
Контроль версий	Git, Mercurial, SVN
Хостинг репозиториев	GitHub, GitLab, Bitbucket
CI/CD	GitHub Actions, GitLab CI, Jenkins
Артефакты	Docker Hub, AWS ECR, Nexus

#Проверка соответствия принципу

Задайте себе вопросы:

Существует ли ровно один репозиторий для приложения?
Развёртываются ли все среды из одной кодовой базы?
Можно ли развернуть production одной командой?
Известно ли точно, какой коммит работает в production?
Можно ли откатиться к предыдущей версии за минуты?
Есть ли у каждого микросервиса своя независимая кодовая база?

#Связь с другими факторами

Config — конфигурация различается между средами, код одинаковый
Build, Release, Run — артефакт сборки один для всех сред
Dev/Prod Parity — одна кодовая база помогает держать среды одинаковыми

#Пример из практики

#До: хаос с развёртываниями

# Компания использует FTP для деплоя
ls prod-files/
├── app.py          ← изменён напрямую на сервере
├── utils.py        ← версия 2.3
├── config.py       ← содержит prod-пароли
└── templates/
    └── index.html  ← версия от вчера

Проблемы:

Непонятно, какая версия работает
Прямые изменения на сервере
Секреты в коде

#После: 12-Factor Codebase

# Git репозиторий
git log --oneline
a1b2c3d (HEAD -> main, tag: v2.1.0) Add payment feature
e4f5g6h Fix login bug
i7j8k9l Initial commit

# Развёртывание
./deploy.sh production
# → Забирает код из Git
# → Собирает Docker-образ
# → Развёртывает в Kubernetes

Результат:

Полная отслеживаемость изменений
Воспроизводимые развёртывания
Быстрый откат при проблемах

Ключевой вывод: Одна кодовая база — это источник истины для всего приложения. Из неё развёртываются все окружения, по ней отслеживается история изменений, к ней привязаны все процессы развёртывания и отката.

✅ Правильно: ┌─────────────────┐ │ Git Repo │ │ (one codebase)│ └────────┬────────┘ │ ┌────┴────┬────────────┐ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌──────────┐ │ Dev │ │Staging│ │Production│ └───────┘ └───────┘ └──────────┘

❌ Неправильно: myapp-dev/ ← разработка здесь myapp-staging/ ← тестирование здесь myapp-prod/ ← production здесь (доступ только у сеньоров)

✅ Правильно: myapp/ ← единый репозиторий ├── src/ ├── tests/ ├── requirements.txt └── .github/workflows/ci.yml Развёртывания: - Dev: git checkout main && DEPLOY_ENV=dev ./deploy.sh - Staging: git checkout main && DEPLOY_ENV=staging ./deploy.sh - Prod: git checkout main && DEPLOY_ENV=prod ./deploy.sh

user-service/ ← кодовая база сервиса пользователей order-service/ ← кодовая база сервиса заказов payment-service/ ← кодовая база сервиса платежей

Окружение

Назначение

Конфигурация

Development

Локальная разработка

Локальная БД, debug-режим

Staging

Тестирование перед prod

Копия prod-данных, debug-режим

Production

Работа с реальными пользователями

Production-БД, debug отключён

CI/CD

Автоматические тесты

Временная БД, изолированное окружение

# Все сервисы в одном репозитории github.com/company/platform ├── services/ │ ├── user/ │ ├── order/ │ └── payment/ └── libs/ ├── auth/ └── logging/

Задача

Инструменты

Контроль версий

Git, Mercurial, SVN

Хостинг репозиториев

GitHub, GitLab, Bitbucket

CI/CD

GitHub Actions, GitLab CI, Jenkins

Артефакты

Docker Hub, AWS ECR, Nexus

# Компания использует FTP для деплоя ls prod-files/ ├── app.py ← изменён напрямую на сервере ├── utils.py ← версия 2.3 ├── config.py ← содержит prod-пароли └── templates/ └── index.html ← версия от вчера

# Git репозиторий git log --oneline a1b2c3d (HEAD -> main, tag: v2.1.0) Add payment feature e4f5g6h Fix login bug i7j8k9l Initial commit # Развёртывание ./deploy.sh production # → Забирает код из Git # → Собирает Docker-образ # → Развёртывает в Kubernetes