How to make a separate .gitignore for deployment on Heroku?

Question

git

Good afternoon. There is a repository on github, there is an account on heroku. I don’t upload .yml files to github, but Heroku needs them for the application to work. How to make it so that you can painlessly push to heroku without constantly editing .gitignore?

Answer 1

For some time now, Heroku has supported Git submodules, which allows you to separate the application code directly from the files needed exclusively for deploying to Heroku. Then the first repository can be stored on a github, and the second one can be hosted inside Heroku, where no one will have access to it.
For example, I used something like this repository structure to deploy a Django application (I'm sure something similar can be done for 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             ┊ ← Используемый рантайм.

Of course, this approach is not without drawbacks (the most serious of which is that you have to maintain a set of almost identical files manage.py, requirements.txt, wgsi.py), but it allows you to:

• get rid of the hodgepodge of disparate files in the root of the repository
  (what religion told the Heroku developers to look for these files in a separate subdirectory, and not the project root?);
  
• effectively separate development and deployment.
  

Answer 2

Use environment variables 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