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 coordinate multiple independent applications across development stages using Git branching and merging. Each Git branch (develop, master, staging) corresponds to a specific Heroku environment, and merging code aligns applications' codebases. The lesson covers configuration management through Procfile and app.json files, plus three pipeline architecture patterns scaled for different team sizes.

Key points

  • Heroku Pipelines manage multiple independent applications across staging, production, and review app environments
  • Git branches (develop, master, staging) directly map to Heroku environments; commits to a branch affect only that branch's app until merged
  • Merging in Git combines code from one branch to another, synchronizing the corresponding Heroku applications
  • Procfile and app.json files configure applications and allow pre-configured add-ons and environment variables to be imported across environments
  • Three architecture patterns exist: 2-layer (develop + production) for 1-2 person teams, 3-layer (develop + staging + production with review apps) for 3+ developers, and 4-layer for large teams where staging can be tested simultaneously with next-phase preparation

FAQ

How does Git branching relate to Heroku Pipeline environments?

Each Git branch (develop, master, staging) corresponds to a different independent Heroku application. Code commits to a branch affect only that branch's application until the code is merged with another branch, which then aligns both applications' codebases.

What is the purpose of the app.json file?

The app.json file allows you to pre-configure and define add-ons and environment variables for an application. This enables importing configurations from existing applications without manually copying and pasting settings to each application copy.

Which Heroku Pipeline architecture should I choose?

Choose based on team size: 2-layer architecture (develop + production) for 1-2 developers, 3-layer (develop + staging + production with review apps) for 3+ person teams to avoid conflicts, and 4-layer for large teams where staging can remain under review while preparing the next deployment.