Managing Multiple Apps from a Single Git Repo
Running multiple apps from a single repo can really come in handy, especially when using dev, QA, staging, production, etc. phases in your development workflow. It's really simple to do on Pagoda Box, requiring only a minor adjustment to your Git workflow. This doc walks managing multiple apps from a single Git repo. After reading it, you should be familiar with:
- Managing Multiple apps from a single Git repo
- Things to know when working this into your workflow
Things to Know
There are a few things to know when managing multiple apps from a single Git repo. They're pretty simple, but still important to understand.
Every App Has a Unique Clone URL
Every app has its own repo on Pagoda Box, each with a unique Git clone url. The clone url is necessary when adding Git remotes. Your app's Git clone url can be found under the "Admin" tab of your app dashboard.
Adding Git Remotes Terminal
# Pattern $ git remote add [remote_name] [git_clone_url] # Example 1 $ git remote add pagoda email@example.com:apps/demo-app.git # Example 2 $ git remote add staging firstname.lastname@example.org:apps/staging-demo-app.git
Each App Should Be Added as a Separate Git Remote
To push a single repo to multiple apps, each app must be added as a unique Git remote. Simply use the pattern explained above to add remotes to your local repo.
Only the Master Branch Will Deploy
When pushing to Pagoda Box, only the "master" branch will deploy. If you're working on a branch other than master, it's possible to push to the master branch of your remote repo with a simple addition to your
git push command. The example below shows how to push your local "staging" branch to the remote "master" branch.
Pushing a Local Branch to the Remote Master Branch Terminal
# Pattern $ git push [remote_name] [local_branch]:[remote_branch] # Example $ git push pagoda staging:master
Workflow for Staging & Production Apps
It's a common practice to have multiple test apps setup for different phases of the app development process (dev, staging, QA, production, etc.). This process becomes especially easy when combining the functionality of Git and Pagoda Box.
Each Development Phase Should Have Its Own App
To test changes in isolation in a live environment, we suggest creating applications for each phase of your development cycle. For example, a development app, a staging app, a production app, etc. Each will have their own unique remote repos and clone urls.
Use Git Branches to Isolate Development Phases
We recommend using Git branching to isolate changes made within each phase of the development process. This allows you to develop on a branch other than master. Then, when changes are tested and proven production-ready, they can be merged into master and pushed to your production app.
Below is an example workflow for a development cycle. Assume two applications have already been created, each devoted to a specific phase of the dev cycle. The names of the apps are "staging-demo-app", and "prod-demo-app." "Feature x" is being developed, tested, then pushed into production.
Example Development Workflow Terminal
#Add a remote for each app $ git remote add production email@example.com:apps/prod-demo-app.git $ git remote add staging firstname.lastname@example.org:apps/staging-demo-app.git #Master will be used as the production branch #Add a staging branch to the repo $ git branch staging #Checkout the staging branch $ git checkout staging #Make changes, add and commit them to the staging branch $ git add . $ git commit -m 'developing feature x' #Push and deploy the staging branch to the staging remote $ git push staging staging:master #Confirm changes are good #Switch to the master branch and merge in changes from staging $ git checkout master $ git merge staging #Push merged changes to the production remote $ git push production master
Table of Contents
- Every App Has a Unique Clone URL
- Adding Git Remotes
- Each App Should Be Added as a Separate Git Remote
- Only the Master Branch Will Deploy
- Pushing a Local Branch to the Remote Master Branch
If you have any questions, suggestions, or corrections, let us know.