Fixes #79: Write an ADR about development environments #80
Conversation
| - **User Acceptance Testing (uat) Environment**: A stable space where end users can try out new features before they are made live. During the testing phase, it is frozen to keep it consistent. This is the prototyping phase. | ||
| - **Production (prd) Environment**: The final phase released to the users. | ||
|
|
||
| We host our website with **Vercel**, which offers a unique way to handle these situations: |
There was a problem hiding this comment.
specific details of implementation should not be included in an ADR, except when we are really, really sure we won't ever change which is not the case for Vercel. Go back to what Vercel is, which is a web hosting service for static files and describe that.
| - Using Vercel makes our CI/CD pipeline better because it automates the deployment process and gives us feedback on changes right away through preview URLs. | ||
|
|
||
| ## Consequences | ||
| - The team must follow the rules for using these environments in a structured way to avoid problems and make sure that the change from development to production goes smoothly. |
There was a problem hiding this comment.
a lot of this implies manual steps when in fact we are automating these.
When documentation is required, handwaving documentation is not sufficient; there needs to be clear where this doc is, how it is written and how it is used.
| - **Single Environment Approach**: putting development, testing, and production all in the same environment (not chosen because of risk and lack of control). | ||
|
|
||
| ## Outcome of the Decision | ||
| We are going to put our production-level apps in three different environments: |
There was a problem hiding this comment.
Don't use "We are going to" implying future state. ADR is to document how we do things now and in the future and especially why we do them.
There was a problem hiding this comment.
systems, not apps
there are more than three
Our systems are deployed in these environments:
|
|
||
| ## Outcome of the Decision | ||
| We are going to put our production-level apps in three different environments: | ||
| - **Development (dev) Environment**: Shows the most recent changes to the any branch. This will allow developers to preview their work before it's sent to real user for testing |
There was a problem hiding this comment.
since there can be multiple concurrent branches on the same repository, better to create one deployment per branch and have dev be an alias to the latest branch deployment.
|
|
||
| ## Outcome of the Decision | ||
| We are going to put our production-level apps in three different environments: | ||
| - **Development (dev) Environment**: Shows the most recent changes to the any branch. This will allow developers to preview their work before it's sent to real user for testing |
There was a problem hiding this comment.
also consider the local developer environment (or the cloud-hosted development environment)
| # ADR-009: Development environments | ||
|
|
||
| ## Summary | ||
| This Architectural Decision Record (ADR) describes how we plan to handle various development environments for testing, prototyping and releasing the different products |
There was a problem hiding this comment.
should probably start with a diagram first to come to a common understanding.
don't forget that you need to think about our common three tier architecture as well as deployment during development vs deployment of the final product in our Agency protected environment.
|
From now on, please also put @ThomasCardin as reviewer on any DevSecOps PR |
I use to do that but the thing was a lot of PRs were getting approved even when he didn't review them yet since he's working only 2 days I'll add him from now on just wanted to give my opinion and true on ADR I should always add him my mistake |
the rule, if the person is absent (vacation, not working, etc), you consider their approval optional; at least they'll be able to comment when they are back with the PR. Also a reason why we shoudn't delete branches as soon as a PR is merged. |
I was not aware about that rule will do |
|
@ThomasCardin this is an important ADR that we need to expand on to explain how we will maintain and deploy our development environments. I've added it back to the DevSecOps backlog. |
|
@ThomasCardin can you follow up on this one? I do want us to clarify what our different environments (branch, staging, prod) are in order to explain the differences to incoming developers. |
#79
also closes #56 I didn't realise I already had a issue open about this my mistake