Document suggested dev branch/testing methodology

[grymmy]

I propose we have three different deployment environments.

One for development, which can get auto-deployed when code gets merged to main. A developer playground.
One for staging, which we can manually deploy to for a stable testing area.
One for production, which we can manually deploy to users in the real world.

[alhardwarehyde]

@leomcelroy is this something we want to do?

[leomcelroy]

How would you recommend setting these up?

[grymmy]

@leomcelroy TBH I think it's fine to leave the "how" of this to the actual implementation, but my first thought is through the use of git tags and changing some of our current ways thing deploy. However we end up doing it, I think it is important for it to be well-documented as a runbook (that can, sooner or later, be scripted/automated for sure) such that anyone w/ proper perms can cut a build to staging/prod if needed.

At the risk of going off-topic here, my opinion is that we would be in a better situation overall, shipping higher quality code, if we more carefully control how code reaches production. Having group understanding of when prod changes in any way is a good thing. Other things like having defined release schedules ("we ship (or attempt to) to prod on Wednesdays, not near the weekend"), testing processes, code reviews, etc also play in here.

[leomcelroy]

Where is the current deployment system articulated?

[grymmy]

Where is the current deployment system articulated?

AFAIK it isn't, and my current understanding is we auto-deploy to production when things are merged to main. PRs are also (if the PR's perms permit, I think) deployed on vercel using branch names...? If someone knows if and where this is documented I'd like to know...

[leomcelroy]

I find that system acceptable, except that it doesn't account for when tagged releases are made (which we are due now).

[grymmy]

I find that system acceptable, except that it doesn't account for when tagged releases are made (which we are due now).

@leomcelroy Sorry - which system? The current system of shipping code landed on main immediately to production, as it stands now, or the proposal?

[leomcelroy]

I find the current system fine. As in it provides continuous updates to main and a way to test dev branches. But agree it should be documented better and we need a tagged release system. Also open to some new approach though.

It does seem to make more sense that a developers playground should be their own branches not main.

[grymmy]

@leomcelroy Okay - I am understanding your feedback here as the following, please correct me if I'm mistaken:

• It would be a good thing to educate people on how they can (and perhaps should) test on their deployed vercel branches.
• You agree that tagging of the main branch for the purpose of cutting production builds on some sort of release schedule is a good thing.

Do you have an issue with having a staging environment then, that could be used to test these tagged production candidate builds? This way we can always point testers to the same URL for testing, and have them do their work prior to prod deployment.

[leomcelroy]

Your summary is good and no issue with staging.

[grymmy]

Note - the scope of this issue has changed and its title has been updated. To whomever picks up this work, please limit work on this issue to adding documentation to the project on how developers can and should use their vercel branch deployments to their advantage, and also suggested best practices.