-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Research Viability and Implementation of Staging Website #78
Comments
Questions:
Update Jan 6, 2022 @sdimran Will work with stakeholder and PM team to determine the need for a staging website when we do not have a viable production mvp for users to use. Issue might be put on hold until MVP status reached. |
Hi @Aveline-art, as discussed though we may not need the full capabilities of a staging site for our landing page initial, when we get closers to our mvp it will be a need. Bonnie confirmed that the drive space will not time out so lets utilize it and get comfortable with working within the staging environment even for landing page initial. lets go through with getting that set up |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Assigning myself this issue to periodically relay updates on my communications with the ops team Jan 12, 2022
|
Jan 20, 2022
|
Jan 26, 2022
|
thank you for the updates @Aveline-art ! |
The ops team has gotten back to me with some minimum requirements for deployment:
Since we are attempting to create a staging environment (with a staging db) before moving onto production (with a production db), we will create a testing environment that tries to mimic a production environment as much as possible, using a temp/testing db. |
Update March 22, 2022: Research stage is complete. The current implementation plan for a staging environment involves
The next step is to complete a demo of how the staging environment would look like. |
Development proposal for directory setup for dev and staging env pipelineNew Directory Structure├── .github/
│ └── ISSUE_TEMPLATE/
├── app/
│ ├── config/
│ └── settings.py
│ ├── frontend/
│ ├── server/
│ ├── .babelrc
│ ├── manage.py
│ ├── requirements.txt
│ ├── package.json
│ ├── package-lock.json
│ └── webpack.config.js
├── dev/
│ ├── django (Dockerfile)
│ ├── webpack (Dockerfile)
│ ├── django.env.dev # will be added to .gitignore
│ └── webpack.env.dev # will be added to .gitignore
├── stage/
│ ├── django (Dockerfile)
│ ├── nginx (Dockerfile)
│ ├── postgre.env.stage # will be added to .gitignore
│ ├── django.env.stage # will be added to .gitignore
│ └── nginx.conf # will be added to .gitignore
├── .dockerignore
├── .gitignore
├── CONTRIBUTING.md
├── LICENSE
├── README.md
├── config.json
├── docker-compose.yml
└── docker-compose.stage.yml Step-by-step (draft) of how our website will be built:
Discussion points/possible problems:
NotesDocker: Multiple Dockerfiles in project Update March 29, 2022
|
Update Mar 30, 2022
|
Update Mar 31, 2022
|
Update April 1, 2022
|
Update April 14, 2022
@sdimran @sharadgaurav7 After meeting with the Ops team, we have come to the conclusion that we need to cut and reduce costs for our configuration. These measures would take time, however. Below are several plans to move forward. Please select the one we would prefer.
|
@Aveline-art for option 2 when you mention the con as small community support, could you expand on what that means? |
Community support means that there is not a large community of developers who uses a certain technology. When something has less community support, it is harder to find solutions to obscure problems or there might not be strict best practices in place. |
Reopening this as there is still more work to be done before this can be completely closed |
Notes from Ops meeting on 11/9/2022 Tasks -
What CTJ needs right now - We want to focus on the staging environment. So that non-developers on the team can see the site before it goes live. We don’t need anything too heavy in terms of resources. We just need to get this up so people can use it and see it. Concerns -
|
I don't believe we need or want stage or prod to use the same tables? I envisioned staging as more of our final test environment to ensure things are good before promoting to prod
FYI, I believe that currently, all DB user accounts (e.g. civictechjobs_stage vs cti_dev) can access any DB in the RDS instance |
That's not good... Is there a way to limit access so that we lower the risk of cross-contaminating data? The worst situation is if someone added test data from staging into the production database as we'll need to manually verify and delete it. If not, I think we need to reconsider the value of using our sole RDS for staging. What ways do we have of testing integration without using the sole RDS instance in staging? |
Overview
As a developer, we need to ensure that our work is easy for the team to review and comment on. For this issue we will conduct all the work needed to create a staging version of our product.
Action Items
Resources/Instructions
Link to current deployment plan
OWASP Top Ten
White-noise
The Ops team at HackForLA manages hosting our various projects. Please make contact with them through Slack under the #ops channel. The stack that they are using are Terraform and AWS, so focus research on those tools.
Concerning the selective upload, GitHub natively have ways of doing this. The slightly more dangerous way is to have two GitHub actions, which runs on dispatch to either the staging or production environment. This is potentially dangerous since reverting is difficult if the the wrong dispatch is accidentally ran without a history of which commit was previously hosted. The better way would be to link it to Github release system, since releases are very purposeful. The final solution might involve a bit of both, but please do broad research on possible options!
The text was updated successfully, but these errors were encountered: