Re-adopt staging branch release strategy

[tim-macphail]

Do this ticket near the end of April, when the product will start actually being used.

In order to have a more stable app, instead of having deployments triggered by merging feature branches into main, either

1. Have a production branch that we need to merge main into that manages deployments.
2. Merge feature branches into a dev branch first and periodically merge dev into main.

In either case, the staging branch should be tested extensively and possibly even deployed to a test environment. Regular deployments could correspond to a MINOR change in the MAJOR.MINOR.PATCH pattern of semantic versioning, important deployments could correspond to a MAJOR change, and patches correspond to PATCH.

[tim-macphail]

I would also like to hear any input from @kamadorueda @racherene on this 🙂

[kamadorueda]

I agree you need to have a development deployment where you can manually test changes, but introducing semver, deployments that happen selectively, and the manual process for managing releases, is not the only approach to ensuring stability and quality, only covers part of the software development life cycle, and requires human intervention (that can be partially automated)

My opinion on this is around the lines of the DevOps ways. This means: having a strong CI/CD that automates testing as much as possible, always deploying ephemeral environments per every branch before main automatically so that you can manually test what cannot be tested by the CI/CD before merging the pull request, and at this point just merge to main, deploy to main automatically, and learn from the instrumentation, logs, monitoring, and alerts that your services (back and front) have included. If a bug escapes the process, just improve the process to prevent it from happening again.

But as always, it's a trade-off, and you need to evaluate each alternative's pros and cons individually without bias. In my experience, DevOps is an upfront cost, but after that, it's a very well-oiled machine that automates as much as possible with the least amount of human intervention. Manual processes do not scale well

Since I also use a SPA for the frontend and lambda for the backend, I can show you how I architected this process at the company I work for, but essentially is what I mentioned before: there is a strong CI/CD, every PR creates ephemeral environments (backend,db,frontend,everything) like $branch.app.holdings.io (e.g. https://kamadoruedaonboarding.app.holdings.io/) automatically, and then everything else is main (e.g. https://app.holdings.io/), and there are logs, monitoring, backups, alerts to catch the bugs that escape all of this

[cloudyyoung]

always deploying ephemeral environments per every branch before main automatically

I know that AWS Amplify frontend can also do this with pretty straightforward settings, deploying to something like pr-237-change-color-scheme.lifeline.techstartucalgary.com for all prs and branches, and admins can limit access to internal with credentials.

---

Regarding the DevOps, it's really ideal to have it than having production branch. But there are many works to do from us to make it to the ground, just as Kevin mentioned, the upfront costs. I think there are two big questions we need to answer: 1) whether we want to take that upfront cost, and 2) how are we making sure to have DevOps done right.

First It's fair to say that all deploy process are people centred, and lifeline team is currently composed by a bunch of students mainly focusing on studying or interning, and have limited or unstable time and effort commitment to such a side-project. There seems to be a big uncertainty in people, it's nothing like a formal job or having a structured management in a workplace. (And I may say things are all a bit messy here for lifeline development, but I think it's ffineee cuz it's a side-project anyways, da looser organization u know) So I wonder, with the amount of uncertainty, if DevOps is going to function properly, what is the tolerance in it. So far I have personally kinda seen examples of DevOps done good job in workplaces with commercial products, but obviously lifeline is simply a whole different situation from that, so maybe we want to see examples of similar projects like lifeline running DevOps to give us more confidence, and possibly learn from them.

(And thinking for the future, it's likely gonna be an open-source and community-driven-ly project from what we see today)

Second, how much work would look like for upfront cost. Comparatively speaking, it's probably fine if it's about 10-20% of work compare to what we have done so far for the project. But if the work is over, say 40-50%, then that implies that we don't actually have that many work done at all and we may be risking to take time and effort to acquire a too strong deploy process than we actually demand, and I don't believe this is a wise choice. We should evaluate that definitely.

And the last, we simply barely have experience with DevOps. It's the fact that there's not a single "right" definition for DevOps, teams/companies all done it differently for fitting their demands. It's like a reading question in essay class that there's no right answer to it. What if we cannot find our way of DevOps, what if we keep trying and never succeeding, what if we never done it right for us...? I don't know how this should go...

Hope I expressed myself correctly!

---

For now I'm just gonna root for the idea of having a production branch, before we draw any conclusion on DevOps (or never). Because we are so unsure of DevOps, the regular "making releases" just sounds a really safe play that it can never go wrong, and it's easier to do with both deploy and our lives. :)

We can have semver, ephemeral env, CI/CD all that stuff. But, just not deploy right from main. Because we YOLO things, and I know that I am always just reviewing PRs casually and give approval as long as it's not ridiculous, and find out bugs afterwards like always (side-projects only tho). And I don't want us to break things on live. LOL.

Oh and I appreciate the effort of Kevin, I think he's really tryna sell the idea of DevOps to us haha!