DevOps: Migrate to action deployments from main

[TangoYankee]

Description

As captured in this discussion on releasing strategies, we should update our releasing strategy. The discussion covers several topics. This ticket focuses specifically on two items: 1) creating a main branch to replace develop and master and 2) Writing github actions to handle staging and production deployments.

Among our legacy applications, Zap Search has a relatively simple deployment. The client application deploys to netlify and the server application deploys to heroku. Both the client and server applications each have a staging and a production environment. This is simpler than other applications because there are no development or data-qa environments.

The end goal is to have the same environments but to simplify their deployment. The end result should: 1) Have a single main branch that is used for basing feature branches and deployments 2) Enforce rebasing and a linear history on the main branch 3) Automatically lint when merging into main 4) Automatically deploy to a staging environment when merging to main 5) Manually deploy to production from main

We need a transition strategy that allows us to test the github actions without breaking existing deployments. This strategy must incorporate netlify and heroku. Both netlify and heroku allow for N number of environments. We would target 4 environments across the 2 applications- a staging-action and a production-action environment for each. For heroku, this would entail manual creation of these two environments. Once these environments are manually created, the draft actions would target these environments. For netlify, these environments are created automatically by setting the alias flag in the deploy to these respective targets.

In addition to these environments, we will also need to create a main branch and GitHub secrets. Because these resources do not currently exist in the repository, we can create them whenever we need them. For secrets, we can start creating and accessing them immediately. We can also create a main branch right away. However, we will delay adding branch protections until after the changes are settled. This way, we can easily squash the working commits and force push them before making main the default branch. Sidenote: Heroku does deploy based on branch name and they do support main as a "deploy" branch name. However, it seems to require 1) deleting master and 2) pushing the change in branch names to the server. The mere act of creating main will not disrupt the existing production and staging environments.

Summary of asks:

• [ ] manually creating staging-action and production-action heroku environments
• [ ] programmatically creating staging-action and production-action netlify environments
• [ ] creating a main branch
• [ ] creating GitHub Secrets

[TangoYankee]

@TylerMatteo feedback requested

[TylerMatteo]

Lgtm. You should have permissions to make staging and production environments in this GH repo, similar to the ones that exist in the equity-tool repo and add secrets as necessary. If you could break down the work of writing the actions to do the deploys into their own Issue(s), that would be great. If we can have others on the team contribute to the implementation, even better.

[TylerMatteo]

Outside the scope for now but something to consider as a next step - we can eventually think about moving our GH actions to a shared repository where they can be parameterized and used across repos. It may not be worth it in this case because this repo and applicant portal are the other apps that follow this specific architecture of having frontend and backend in the same repo, but something to keep in mind.

[TangoYankee]

If you could break down the work of writing the actions to do the deploys into their own Issue(s), that would be great.

Whoops, they're already written. I'm at the stage of validating the actions by running them against disposable environments.

[TangoYankee]

Moving into sprint M.

We need to strategize on how to safely transition from a heroku cli deployment to a github action deployment. Two big considerations- 1) how to validate that the removed environment variables were truly unused and 2) how to minimize downtime and risk when pointing the github action at staging and then production front and backend environments.

The capital planning project is taking our bandwidth until the end of Sprint L. But with the capital planning project, we should also gain experience with github actions that we can then apply here to zap-search.