Heroku - 12 Heroku Pipelines and Git and Mergers

In the previous lesson we discovered that a Heroku Pipeline holds several applications, each one representing a stage of development (development, staging, production, plus disposable review apps). They all share the same source code but live as independent apps: some are used for testing, while production is the one users actually access. The natural next question is: how do we manage the code that flows between these independent applications? This is where Git enters the picture.

Branches, merges and the pipeline

Git is a prerequisite for this course, so we will not go into all its details. The key idea is that Git lets you create branches, which are copies of the code that can evolve independently. A typical setup has three branches, for example dev, staging and master. Each branch is totally independent: a commit on dev only affects the development Heroku app, a commit on staging only affects the staging app, and a commit on master only affects production. When you are happy with the progress on dev and want to push it forward, Git provides merge: merging dev into master does not delete any application, it simply makes both branches share the same code, and therefore both Heroku apps share that code too. That correlation between Git branches and Heroku pipeline stages is exactly how Heroku spares you from manually managing infrastructure plumbing.

Sharing configuration via app.json

Beyond code, you also need to share configuration: add-ons, environment variables and the like. The trick is that, in the root folder of the project (in any language), you can drop a file called app.json. Heroku reads it to know how a new app of this kind should be configured. The Heroku docs explain every field; keys such as name, description, website, repository, logo and success_url are mostly metadata for humans and have no real impact on the runtime, while the genuinely operational keys (env vars, add-ons, formation, scripts) drive the actual setup so new apps in the pipeline are configured exactly like the source app.

Choosing a pipeline architecture by team size

Finally, this lesson covers the trade-offs between three pipeline architectures. The two-layer architecture (staging + production) is the simplest and fits a team of one or two developers; everyone agrees informally on who owns which part of the code, you push to master, you test on staging, and you promote to production when everything works. The three-layer architecture (development + staging + production) is better when the team grows past two or three people: chaos appears if everyone commits directly to staging, so staging is reserved for code that is "ready to be tested", developers work on review apps until they think their change is ready, then propose to move it to staging and finally to production once tests are green. The four-layer architecture adds an extra step for large teams, where code can sit in staging for several days; an additional environment lets the team prepare the next release in parallel while the current candidate is still being validated. Pick the architecture that matches your team — see you in the next lesson.

Summary

This lesson explains how Heroku Pipelines integrate with Git branching and merging workflows to manage code across multiple environments (development, staging, production, and review apps). Learn how Git branches correlate to Heroku environments, how merges move code between stages, and how to configure applications using Procfile and app.json files. The lesson also covers team architecture strategies ranging from two-layer to four-layer setups based on team size.

Key points

  • Git branches (dev, staging, master) directly map to Heroku Pipeline environments; commits to each branch affect only the corresponding application
  • Git merges synchronize code between environments—merging dev to master updates both the development and production applications with the same codebase
  • Use Procfile and app.json files in your project root to pre-configure add-ons and environment variables across all applications without manual duplication
  • Two-layer architecture (development + production) suits small teams of 1-2 developers; three-layer adds staging for teams of 3+ to prevent testing conflicts
  • Review apps are disposable environments created for pull requests, enabling testing before merging to the main pipeline branches
  • Four-layer architecture (dev → staging → production + review apps) is ideal for large teams, allowing parallel preparation of next deployments while current code is in testing

FAQ

How do Git branches relate to Heroku Pipeline environments?

Each Git branch corresponds to a Heroku Pipeline environment. Commits pushed to the dev branch affect only the development app, commits to the master branch affect production, and commits to staging affect the staging app. This mapping allows independent code management for each environment.

What is the purpose of Procfile and app.json in Heroku projects?

Procfile and app.json files enable you to pre-configure applications with add-ons and environment variables. This prevents manual duplication of configurations across different applications and environments, saving time and reducing errors during setup.

What team architecture should we use based on our team size?

Teams with 1-2 developers should use two-layer architecture (development + production). Teams with 3+ members benefit from three-layer architecture (development + staging + production) to prevent conflicts during testing. Large teams should consider four-layer architecture to allow parallel work on the next deployment while current code is being tested.