Ответ
В моем последнем проекте на Django процесс перед деплоем включал следующие этапы:
1. Сборка и тестирование:
# Запуск тестовой сборки
python manage.py test --settings=settings.test
pytest --cov=.
# Проверка качества кода
flake8 .
black --check .2. Подготовка артефактов:
- Сбор статических файлов:
python manage.py collectstatic - Применение миграций БД:
python manage.py makemigrations && python manage.py migrate - Создание Docker-образа с тегами версий
3. Staging-развертывание:
# docker-compose.staging.yml
version: '3.8'
services:
web:
build: .
environment:
- DJANGO_SETTINGS_MODULE=settings.staging
- DATABASE_URL=postgresql://...4. Проверки перед production:
- Smoke-тесты на staging
- Проверка метрик (response time < 200ms, error rate < 0.1%)
- Валидация конфигурации Nginx и Gunicorn
- Бэкап production базы данных
5. Подготовка миграций:
# migrations/0002_add_user_profile.py
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [('users', '0001_initial')]
operations = [
migrations.AddField(
model_name='user',
name='profile_picture',
field=models.ImageField(null=True, upload_to='profiles/')
)
]Ответ 18+ 🔞
А, ну это ж классика, ебать мои старые костыли! Слушай, как я обычно свой Django-проект на боевой сервер отправляю. Это не просто так, на авось, а целая операция, ёпта. Волнение ебать, каждый раз как в первый.
1. Сначала всё проверяю, как одержимый. Вот эти команды — моя мантра, блядь. Запускаю тесты, а сам сижу и бздю, что что-то сломается.
# Запуск тестовой сборки
python manage.py test --settings=settings.test
pytest --cov=.
# Проверка качества кода
flake8 .
black --check .Если black ругается, что код не отформатирован — это пидарас шерстяной, который последний коммитил, сразу ясно. А если тесты падают — ну всё, пизда рулю, можно идти кофе пить и разбираться, какого хуя.
2. Потом начинается шаманство с артефактами.
Собираю статику — python manage.py collectstatic. Эта команда иногда творит чудеса, а иногда просто молча смотрит на тебя, как манда с ушами, и ничего не делает. Потом миграции. makemigrations && migrate. Тут главное — не накосячить, а то будет вам хиросима и нигерсраки в базе данных. Потом Docker-образ собираю, с тегами. Без этого никуда.
3. Деплой на staging — это как генеральная репетиция перед концертом.
Поднимаю всё через docker-compose.staging.yml. Выглядит всё прилично, вроде.
# docker-compose.staging.yml
version: '3.8'
services:
web:
build: .
environment:
- DJANGO_SETTINGS_MODULE=settings.staging
- DATABASE_URL=postgresql://...Но под капотом-то всегда какая-нибудь фигня: то переменная окружения не подтянулась, то порт занят. Обычная история.
4. А вот это самый ответственный момент — проверки перед продакшеном. Запускаю smoke-тесты на staging. Смотрю метрики: если response time больше 200ms — это пиздец, надо искать, где тормозит. Error rate больше 0.1% — тоже не комильфо. Потом ещё конфиги Nginx и Gunicorn прогоняю взглядом. И, конечно, святое дело — бэкап продакшен базы. Перед этим у меня всегда терпения ноль ебать, потому что понимаю — один неверный клик и можно всё похерить.
5. Ну и отдельная песня — миграции базы. Вот смотри на этот код, вроде ничего сложного.
# migrations/0002_add_user_profile.py
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [('users', '0001_initial')]
operations = [
migrations.AddField(
model_name='user',
name='profile_picture',
field=models.ImageField(null=True, upload_to='profiles/')
)
]Но когда ты применяешь такую миграцию на живой базе с овердохуища записей, у тебя волосы дыбом встают. А ну как заблокирует таблицу на полчаса? А ну как что-то пойдёт не так? Сам от себя охуеешь, пока ждёшь. В общем, процесс это нервный, но если всё делать по уму, а не как распиздяй, то в итоге работает. Главное — не торопиться и десять раз всё перепроверить.