Creating a development environment, Phase 2, documentation

[Aveline-art]

Dependency

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

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 document our findings from the feasibility tests on #2251 so that this information will be available to future maintainers of our separate environments.

Action Items

• Read the Resources/Instructions below to find links to information about how we are propagating data from one repository to another
• Write documentation that reflects the above mentioned process. Be sure to detail:
  • Programs that are used
  • Steps to perform the change propagation
  • Anything else of note
• This documentation can exist in a new wiki, an existing wiki, and even multiple wikis. Just make sure that the information is at an appropriate place.
  • Link to wiki: https://github.com/hackforla/website/wiki/Development-and-Production-Environments
• Ahead of a meeting, send the wiki links on slack, then discuss it at the next scheduled all-team meeting. If you cannot make it, ask a proxy to take your place.
  • Topics include:
    • What settings should be in the prod repo? For example, should people be able to create issues and make PRs?
    • Other topics, please add on.
• Make any additional edits needed to the wiki
  • Note: We are currently in the process of moving the old wiki to the new website-wiki repo, so we will not be making any changes or additions to the old wiki at this time. Thus, we will be adding wiki content through a different process now. Read How to Contribute to the Wiki
• Conduct further research into the details of how this technology could work
  • Can we still give volunteers appropriate credit?
  • How can we handle unaccepted changes?
  • Is it possible to only sync certain files/features?
• Get one of the Merge Team members or a Technical Lead to approve the documentation. See https://www.hackforla.org/projects/website
• Release dependency on Creating a development and UAT environment, Phase 3, admin tasks #2264

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

Github actions to use:

• Git Sync Action
• Merge Branch
• Usage examples - https://github.com/blakes24/hflatest-dev2/tree/main/.github/workflows

[blakes24]

Link to wiki: https://github.com/hackforla/website/wiki/Development-and-Production-Environments

[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 26, 2021 at 12:03 AM PST.}

[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, November 2, 2021 at 12:03 AM PST.}

[mjshelton12]

Update 4/18

Dev Leads have looked over the documentation. While they believe it is thorough and well done, they have reservations on whether or not this technology should be implemented in the way it was originally planned or at all. Due to this, they are not comfortable approving the documentation.

They requested I reach out to the volunteer that initially created the issue to see if she had any insight into the goals/history. She did not.

My next step will be to bring this issue to the 4/23 meeting to discuss the following:

• What is the goal of making use of this tech?
• What would be the best way to make use of this tech?
• Does the current plan meet the goals/is it the best way to make use of this?
• What do next steps look like for me to complete this issue?

[mjshelton12]

Update 4/23

A new presentation was given during the All-Team Meeting on this day with this slide dec - This time to go over issues brought up by Dev Leads after a review of the documentation.

Here are the notes:

• Bonnie and the team are excited about the idea in concept, as long as we can get the nitty-gritty details ironed out
• How should we set these environments up?
  * Currently we are favoring two repositories. One will be Dev with two branches (Main and UAT) where a "secret" site is hosted for product to review and the other will be Prod with one branch where the live site is hosted for users.
  * This is also more similar to enterprise work - it's how companies do it.
  * If we find it's too much work, we can have a rollback plan where we basically ignore the UTA branch and host the dev environment out of the main branch.
  * Questions were raised on how to ensure the right people got credit for their work - Would syncing/mirroring make it look like the Dev Leads did all the work? We want to be sure we are giving volunteers credit both because they did the work and so it's reflected in their github.
• What is the fate of our current repository?
  * The current repository would become our Dev repo, as it's easy to change the domain to a new repo but making a new Dev repo would mean all volunteers would have to re-fork the new one which would be a big hassle.
• Further questions:
  * What happens if a change is not accepted? Right now, we are able to reverse the pull request, can we do that once we've synced to the new branch? Can we reverse the PR and then re-sync the branches?

The main points I will be researching moving forward:

• Can we still give volunteers appropriate credit
• How can we handle unaccepted changes
• Is it possible to only sync certain files/features

[roslynwythe]

@ExperimentsInHonesty Questions:

• As I understand it, the proposal is to setup GitHub Pages in the website-dev repo to serve the UAT branch, and it will not be possible to serve the main branch. So if the main branch will not be available for testing, I'm unclear on the utility of the main branch and why it is worth the effort of the additional merge step.
• To summarize the remaining work on this issue, these questions were raised:
  • will volunteers still receive appropriate credit for their contributions? (I believe that they will)
  • what will be the process for reverting unaccepted changes from UAT? What about if changes have been synced to website-prod?
  • is it possible to only sync certain files/features?

I would like to add a question:

• How will we protect the website-prod repo so that only authorized users can deploy to production?
• Who will be the authorized users who can deploy to production and how will they be notified of what needs to be tested?

Should I update the issue so that it calls for answering these questions and adding the answers in the wiki?