FullStackCodeEnvironments
Both the client and server repositories now follow these minimum branching practices. Code should flow from:
feature branch -> development -> staging -> production
Every stage requires at least one reviewer before moving to the next stage. This forces group collaboration. 😊
When a new issue/bug/feature is created, a feature branch should be made to work on said problem. After the feature is complete, a pull request should be made to merge your code into the development code space.
Resolve any merge conflicts with the other individual your code is conflicting with. Do not assume you know how to fix the conflict by yourself. This is a great time to get someone else involved for a code review and receive constructive feedback.
The development branch is used to collect the code to ensure it is merge conflict free. This is a playground area that has many new concepts and features floating around that should not break existing code, but could.
The staging branch is used to run tests and final checks before the code is pushed to production. This code holds more stable features and should be almost identical to the live code.
This is the live code. Everything in here is shown to the public. No tests or features should go straight to the production branch. Everyone on the team must agree in pushing the code to production if they are involved in any of the new features that made it in the sprint.
THIS SHOULD BE RUNNING AT ALL TIMES
The master branch's purpose was different for client and server. To resolve the ambiguity, we removed the master branch and made the development branch the default branch for both client and server.
Our client is hosted on one Netlify account. In order to run three environments in one account, we rely on Netlify's context configuration.
In our client code we have a netlify.toml file that consists of the following:
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
[context.production.environment]
REACT_APP_AURA_SERVER_API = "https://aurelia-server.herokuapp.com/api/"
[context.branch-deploy.environment]
REACT_APP_AURA_SERVER_API = "https://aurelia-server-staging.herokuapp.com/api/"
[context.deploy-preview.environment]
REACT_APP_AURA_SERVER_API = "https://aurelia-server-staging.herokuapp.com/api/"
[context.development.environment]
REACT_APP_AURA_SERVER_API = "https://aurelia-server-development.herokuapp.com/api/"
[context.staging.environment]
REACT_APP_AURA_SERVER_API = "https://aurelia-server-staging.herokuapp.com/api/"Please refer to Netlify's Deploy Contexts page for more information on our netlify.toml file.
We set up each branch, deploy-preview, and branch-deploy to have a different server API endpoint depending on what branch you are currently on.
Our server is hosted on three different Heroku apps (development, staging, production). Each of the Heroku apps has the necessary environment variables in place to configure connections to our MongoDB databases.
Our data is hosted in three different MongoDB Atlas instances (not clusters, just databases) with names almost consistent with our branch names:
- development
- staging
- aurelia: This was the original production database, but I didn't want to mess with it at the time in case of data failure.
We came up with a graph to show how each code branch from the client connects to each code branch on the server.
