define production workflow

[JohnRDOrazio]

Once we have a skeleton app up and running, perhaps it would be useful to create a development branch, so that all development would be merged first into the development branch, and when a number of significant features have been added and tested they can be then merged to the "main" or production branch.

I could then create a vhost for staging, which would be synced to the development branch, so that there can be a "production ready" website and a "staging" website. Features can pass through the staging website before being pulled definitively into the production website.

[kas-catholic]

Seems reasonable to me, it could be nice to have a staging environment.

We might consider, instead of creating a development branch, we could create a prod branch and use main for development. That way, the typical workflow of opening PRs against main remains intact.

[JohnRDOrazio]

That works too!

[mftruso]

IMHO main represents the current state of the codebase. Work should be done on a feature branch and then when the feature is complete it should be merged into main. When a release is "cut", create a tag to mark what state the code was in at that point in time. This solves

1. There's a single branch to make PRs against which is easier for contributor clarity
2. CI/CD is less complex as anything merged to main could be automatically deployed to the stage site.
3. git history is cleaner as there are no merges from dev to main
4. If you have to back out a feature, you only have to fix it on main instead of dev and then merge that to main

That being said, whatever makes sense to the group is fine by me!

[JohnRDOrazio]

In my understanding, SVN traditionally has a workflow where development is done in the main branch (called "trunk"), which meant that trunk might not be stable and you wouldn't necessarily be able to build trunk until all the bugs were worked out. Stable releases are produced by creating a new release from a previous stable release, then cherry-picking the desired changes for that release from trunk and pulling them into the new release.

Whereas the GitHub approach had traditionally been to consider the "master" (or "main") branch as the current stable build of a project, features are tried and tested in feature branches. And here there are two approaches: pull features directly into "main" (which therefore isn't necessarily the latest stable release, until features have been fully tested in the main codebase), or pull features into a "development" branch. In the last approach, you guarantee that "main" is always stable: new features are pulled into the development branch which isn't guaranteed to be stable until the features have been fully tested, and only after testing and bugfixes, the "development" branch is then merged into the "main" branch which will be the new stable build. And a snapshot of the main branch at this point will be created as a new release.

What I like about this last approach is that the main branch is always guaranteed to be buildable. So that is a new developer joins the project a ways down the road, and tries building for the first time off of "main" , they won't be discouraged by build errors due to a non stable branch

[JohnRDOrazio]

OpenOffice for example had an SVN repo (only recently did they move to GitHub, smart move in my opinion). When in the past few years I tried to do my first builds of OpenOffice off of trunk, I would get quite discouraged by running into numerous errors, and I thought it was just me not having enough experience in doing builds. Until I realized: trunk isn't stable and can have bugs. If you want to do a build that succeeds, you should start from the latest stable release.

Whereas when participating in projects on GitHub, I saw that they made better use of branches for development rather than just tags for releases, so that development could be done in branches before being merged into the main "currently stable" codebase. This made so much more sense to me and made it easier for newcomers to join and start building right away.

As for reverting a change, the idea of having a "development" branch as a filter before merging into "main", is to test features as much as possible, so that they are only merged into main when there is a certainty that they will contribute to the project, and should not have to be reverted. You can always revert in the development branch before merging to main. Once you have merged to main, you are guaranteeing that that feature will be a part of the project, so there should be an idea of "no going back". Reverting after merging to main becomes more complex, but it shouldn't have to happen if the features have been fully tested first. If for any reason something does need to be "reverted" after merging to main, there should rather be a fix that is pushed down from development to main, rather than trying to revert from main backwards

[mftruso]

pull features directly into "main" (which therefore isn't necessarily the latest stable release, until features have been fully tested in the main codebase)

I would argue that when you merge into main you should have some assurance that the build is stable. This can be accomplished with some simple CI task to run tests before a PR can be merged. See a github actions example of a CI workflow: https://github.com/gorails-screencasts/heroku-continuous-deployment/blob/master/.github/workflows/ci.yml

[kas-catholic]

I'm a huge fan of https://trunkbaseddevelopment.com/. Which is roughly in line with what @mftruso outlined above (though some bits of those suggestions are for projects much bigger than ours).

I agree that CI (which we don't currently have, but which I can set up) can ensure that main is always "buildable" (in our case, tests pass and rails starts). In general, you can make a branch and do as much work there as you want to as long as PRs are opened against main and CI passes before merging to main.

[JohnRDOrazio]

Yeah that would work, if we can have CI put into place that would be great. That's how projects like WordPress / Gutenberg handle their projects, they also use "main" as the development branch as long as each PR passes the CI tests. I'm up for that! Though I'm no expert in setting up CI tests, so if anyone knows how to do that, that would be great

[kas-catholic]

CI is in place! See #15