@Ciscoridze

Как сделать отдельный .gitignore для деплоя на Heroku?

Добрый день. Есть репозитарий на гитхабе, есть аккаунт на хероку. На гитхаб я не заливаю .yml файлы, а на хероку они нужны для работы приложения. Как сделать так, чтобы можно было безболезненно делать push на хероку без постоянных правок .gitignore?
  • Вопрос задан
  • 2564 просмотра
Решения вопроса 1
@firegurafiku
С некоторых пор Heroku поддерживает сабмодули Git, что позволяет разделить непосредственно код приложения и файлы, необходимые исключительно для деплоя на Heroku. Тогда первый репозиторий можно хранить на гитхабе, а второй — хостить внутри Heroku, где к нему не будет ни у кого доступа.

Например, я использовал примерно такую структуру репозитория для деплоя Django-приложения (уверен, нечто подобное можно придумать и для RoR):

django-application-heroku   ┊ ← Рабочая копия репозитория для Heroku.
│                           ┊
├── project                 ┊ ← Сабмодуль с кодом, указывающий на GH.
│   ├── django_application  ┊ ← Непосредственно код и данные самого
│   │   ├── locale/         ┊   приложения, которые ничего знать не
│   │   ├── migrations/     ┊   знают о Heroku. Структура файлов и
│   │   ├── templates/      ┊   каталогов, обычная для Django-проекта.
│   │   ├── admin.py        ┊
│   │   ├── apps.py         ┊
│   │   ├── models.py       ┊
│   │   ├── urls.py         ┊
│   │   ├── views.py        ┊
│   │   └── (...)           ┊
│   │                       ┊
│   ├── django_project      ┊
│   │   ├── settings.py     ┊ ← Базовая часть конфигурации, неизменная
│   │   ├── urls.py         ┊   при любом способе деплоя.
│   │   ├── wsgi.py         ┊
│   │   └── (...)           ┊
│   │                       ┊
│   ├── manage.py           ┊ ← Раннер и конфиг с закреплёнными версиями,
│   └── requirements.txt    ┊   используемые на машинах разработчиков.
│        	            ┊
├── bin                     ┊
│   └── post_compile        ┊ ← Вспомогательный скрипт, который сам
│        	            ┊   запускает миграции БД при успешном деплое
│                           ┊   на Heroku.
│        	            ┊
├── manage.py               ┊ ← Такой же раннер, что и в рабочем репозитории,
│        	            ┊   но использует heroku-settings.py в качестве
│        	            ┊   конфигурации приложения вместо settings.py.
├── requirements.txt        ┊ ← Закреплённые версии специально для Heroku.
│        	            ┊   Тот же набор, что и в рабочем репозитории,
│        	            ┊   плюс дополнительно пакеты gunicorn,
│        	            ┊   dj-database-url и WhiteNoise.
├── heroku_settings.py      ┊ ← Конфигурация приложения специально
│        	            ┊   для Heroku. Например, приводит DATABASE_URL
│        	            ┊   к формату, понятному Django.
├── heroku_wsgi.py          ┊ ← То же, что и wsgi.py, но с конфигом Heroku.
├── Procfile                ┊ ← Запускает gunicorn с нужными параметрами.
└── runtime.txt             ┊ ← Используемый рантайм.


Конечно, данный подход не лишён недостатков (наиболее серьёзный из которых — приходится поддерживать набор практически одинаковых файлов manage.py, requirements.txt, wgsi.py), однако он позволяет:
  • избавиться от мешанины разрозненных файлов в корне репозитория
    (какая религия помещала разработчикам Heroku искать эти файлы в отдельном подкаталоге, а не корне проекта?);
  • эффективно разграничить разработку и деплой.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@exvion
Воспользоваться переменными окружения https://devcenter.heroku.com/articles/config-vars
cd myapp
$ heroku config:set S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars and restarting myapp... done, v14
S3_KEY:   8N029N81
S3_SECRET: 9s83109d3+583493190
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы