Pre-requisites for front and backend env setup

[Aveline-art]

Overview

As a developer, we need to ensure that this project is properly setup such that developers can come in and pick up the work and our data is protected. For this issue we will be researching the best ways to set up our environment.

Action Items

• [x] Find a solution for hiding the database and other sensitive secret keys when uploading to GitHub
• [x] Find a solution for linking our repo to AWS
  • [x] Find out what the AWS requirements are, and the best way for the team to meet these requirements.
• [ ] Find a solution to changing the debug and other settings back to their previous configurations when in development vs production on hold until we are ready for deployment
• [x] Release dependency on #25

Resources/Instructions

Questions to consider before AWS deployment:

• [ ] Is our gain from deployment worth the cost of AWS? If not, what do we still need to do before we can deploy?

[Aveline-art]

• Progress: Currently attempting to follow this tutorial to get started. Once docker is set up, I plan to deploy to AWS.
• Blockers: Tutorials do not anticipate bugs, so debugging has been difficult.
• Availability: 2 hours
• ETA: Unsure, as this is all new to me. 13 work hours sound like a good estimate

[Aveline-art]

Update:

Notes on AWS:

• AWS integration is handled by the #ops team. The basics is that a project AWS account is linked to an organizational level account for billing and hosting purposes. We need admin access to create and link accounts.
• To put a project in AWS testing, it uses an incubator which is found in hackforla/incubator. To test AWS hosting, we need to format our configurations to meet the needs of the incubator.
  • The ops CoP folder contains videos for using the incubator
  • This incubator is also managed by #ops
  • The incubator uses a GitHub actions for deployment. I believe this GHA needs to be copied over to a repo that needs AWS.
  • List of configurations include: terraform file (more to come)
• Docker should not to database migrations, but rather the migrations need to happen manually. How this works in production is unknown and needs to be solved down the line.

[Aveline-art]

Update:

Notes on hiding sensitive information:

• Secret keys can be hidden via an env file, or outside callable file (for example a python file for the Django keys). This key needs to be shared privately, perhaps via our drive, and it should never be uploaded to GitHub.
• The database is a little trickier, since it contains data. Until it is deployed (and maybe even after it is deployed), we need to leverage Django's ability to perform unittests. This is where having a clear schema is important as it allows us to outline how the unittests should be made.

[Aveline-art]

Closed because discussion is done, and we are ready to set up the development environment.