Feasibility: Creating a development environment for our website, Phase 1

[Aveline-art]

Overview

As a developer, we are interested in creating environments for our websites that are friendly for the whole team to review. For this issue, we will create a demo to test and document ways our workflow will change due to creating a development and UAT environment.

Action Items

• Read the Resources/Instructions below to get a sense of what a development and UAT environment is.
• In your own account, create two repositories named username/hflatest-prod, username/hflatest-dev.
  • For each repository, we need to have the same files in each, and each must be configured such that it can be deployed to GH-Pages. Each resulting website must be exactly the same.
• Figure out a way to move changes from hflatest-dev to hflatest-prod.
  • This does not need to be a program. It can be a GitHub feature (if exists), or manually done through copy and pasting.
  • Regardless of the solution, please document it in this issue.*
• Also, confirm that renaming the repository will not break any of the hosted websites. You can do so by renaming them from hflatest-prod to hflatest-rename.
• In a demo during a meeting, showcase how changes are moved from one repository to the next.
• Release dependency on Creating a development environment, Phase 2, documentation #2266
  • Include a link in the Resources/Instructions section to details on our chosen method for moving changes.

*Note: There might be several viable solutions. In that case, please document all of them so that the team can discuss the pros and cons of each.

Resources/Instructions

This issue concerns creating new environments for the HackForLA website team. Documentation below will go into more details, but to briefly summarize, we want to transition from one environment to 2:

1. hackforla/website-prod - this environment will be a production environment, meaning code here is for a website made specifically with external clients in mind
2. hackforla/website-dev - this environment will be exactly like our current environment. As the issue taker, you should be familiar with how this works. The only difference is that changes here will be propagated to prod instead of reflecting on the website.

Notice how each of the environments are worded like a repository--because they are! For each environment, we are interested in hosting different versions of the website. We use GitHub pages as our host, which means that it is impossible for us to host three sites off of one repository. Therefore, the key to this issue is to find a method through which changes can be propagated from DEV -> Prod.

Development, testing, acceptance and production

[Aveline-art]

@hackforla/website-pm Please let us know that, if we create a dedicated environment for UAT, what is the ideal setup? That is, if the developers create this environment what are the MVP requirements?

[blakes24]

Update

• Github Actions can be used to move changes between repos
• also possible to use Travis CI but there's no clear benefit, and it requires extra setup
• Git Sync Action seems to be the best option - it can be triggered to sync the prod repo to the current state of any branch from the dev repo
• other actions are possible depending on how we want things to work
• changing the repo name shouldn't break the hosted websites but I can't test this without a custom domain
• changing the repo name would affect some of our github actions

How should it be structured?

• 3 "branches"
  • Dev repo with a Dev branch and a UAT branch (or whatever we want to name them)
  • UAT branch is published
  • Prod repo has one branch that receives changes from UAT branch of the dev repo when approved
  • allows changes to be merged to dev without affecting the UAT website
• 2 "branches"
  • each repo has one primary branch
  • Dev website is always up to date with current changes, which are then pushed to prod upon approval

[github-actions]

@blakes24

Please add update using the below template (even if you have a pull request). Afterwards, remove the 'To Update !' label and add the 'Status: Updated' label.

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. Pictures: "Add any pictures of the visual changes made to the site so far."

If you need help, be sure to either: 1) place your issue in the developer meeting discussion column and ask for help at your next meeting, 2) put a "Status: Help Wanted" label on your issue and pull request, or 3) put up a request for assistance on the #hfla-site channel.

_{You are receiving this comment because your last comment was before Tuesday, October 5, 2021 at 12:02 AM PST.}

[blakes24]

Update

• we decided on a 3 "branch" structure
• there will be a main and a UAT branch in the dev repo
• there will be a manually triggered github action to merge changes into the UAT branch
• the site will be built from the UAT branch of the dev repo
• there will be a manually triggered github action that moves changes from the UAT branch to the production repo
• examples of the github actions - https://github.com/blakes24/hflatest-dev2/tree/main/.github/workflows
• disable actions on prod repo to prevent duplicate actions