feat/code-pipeline

[jusdino]

Description List

• Added CDK app and documentation for multi-account environment setup
• Added CodePipeline for deployment of test/prod environments
• Added frontend state upload license form UI
• Added frontend dev deploy pipeline

Testing List

• Code review
• Review compact-connect/README.md and multi-account/README.md for clarity

Closes #31
Closes #38
Closes #37
Closes #39

[waldoj]

Here's the review checklist that I'll work my way through in reviewing this PR:

• review the pull request to get oriented
  • read the description of the pull request, which should summarize the changes made
  • read through every task on the Scrum board that's encompassed by this pull request
  • read the description of the commits that comprise the pull request
• stand up the site locally
  • test all functionality in all major browsers, emphasizing the functionality that this pull request addresses
    • for public-facing functionality, test in browsers consistent with public browser use data
    • test in Mobile Safari and Mobile Chrome
  • use an automated audit tool for code quality and practices (recommended: Chrome DevTools, aka Lighthouse)
    • look at efficiency of page loads, asset sizes, HTTP connection management, etc.
  • review for accessibility
    • use an automated audit tool, such as Chrome Audit or aXe
    • navigate site only with the keyboard
    • use VoiceOver or Narrator to navigate the site with audio only, with the display turned off
    • manually test anything that pa11y cannot test automatically (e.g., contrast of text over images)
• review static code analysis results
• run a security audit of dependencies (e.g. npm audit) to ensure that there are no vulnerabilities that will be deployed to production (as opposed to vulnerabilities that only have an impact on the development environment)
• examine OWASP ZAP output to ensure that any errors are known to be false positives or have been previously declared to be acceptable
• skim all new code, in the context of existing code, looking for problems (knowing that the vast majority of new code will be covered by tests)
• review all tests
  • methodically review all new tests for correctness, quality of naming
  • look at code coverage of tests
  • determine what code isn’t tested, review that rigorously
• review documentation to ensure that it matches changes
• provide comments on the pull request on GitHub, as necessary
  • for comments that are specific to a particular line of code, comment on those specific lines
  • for comments that are more general, attach the comment to a random line in README.md (as opposed to commenting on the pull request itself), to be able to use GitHub's ability to thread discussions on those comments
• for each feature-level bug (i.e., it’s working as designed, but designed wrong), open a new issue and put it in the backlog

[waldoj]

@isabeleliassen, I have reviewed this pull request, evaluating it for conformance with the QASP, and conducting a code review. I recommend that the pull request be merged into CSG's repo.

[waldoj]

Phew!

[waldoj]

✔️