Deploying to Heroku via Git

WHAT THIS TESTS This verifies you understand the convention-over-configuration deploy model of a git-based PaaS and which files drive the build.

A GOOD ANSWER COVERS You develop locally and commit your code to git. You add the platform as a git remote, then run git push heroku main. On receiving the push, the platform selects a buildpack by inspecting your repository: a requirements.txt signals Python, a package.json signals Node, and so on. The buildpack installs your dependencies into a build, compiles the result into a deployable artifact called a slug, and starts the process types declared in your Procfile, for example web: gunicorn app:app, which tells the platform what command runs the web process. Key files are the dependency manifest (requirements.txt, package.json, or pom.xml), the Procfile that declares the start command, and often a runtime version file such as runtime.txt or an engines field to pin the language version. Secrets like the database URL are supplied as config vars set on the platform, not committed.

COMMON WRONG ANSWERS Confusing the dependency manifest with the Procfile; one lists libraries, the other declares the start command. Forgetting the Procfile entirely, so the platform does not know how to run the app. Hardcoding secrets in the repo. Thinking you upload files manually rather than pushing git.

LIKELY FOLLOW-UPS What is a buildpack and what does it do? Where do environment variables and secrets live? How do you run database migrations on deploy via a release phase? How do you scale the web and worker process types?

ONE CONCRETE EXAMPLE A Flask app has app.py, requirements.txt listing flask and gunicorn, and a Procfile containing web: gunicorn app:app. You run heroku create, set config vars with heroku config:set DATABASE_URL=..., then git push heroku main. The Python buildpack installs the requirements, builds the slug, and launches gunicorn, and the app is live on a Heroku URL with no server administration.