С некоторых пор 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 искать эти файлы в отдельном подкаталоге, а не корне проекта?);
- эффективно разграничить разработку и деплой.
