search

jlefkoff / GridBoard

a project to use an LED matrix for grid based games for the '21 Interactive art installations winterm
MIT License
0 stars 1 forks source link

Discuss branching strategy #5

Closed gsalaman closed 3 years ago

gsalaman commented 3 years ago

We're probably at the point where we want to have a "production" branch (with the latest stable code) and use development branches to flush out the individual pieces, later merging them into the production branch once they are stable.

Let's talk about a strat for doing this.

jlefkoff commented 3 years ago

Maybe a framework branch and branches for new games? I can create one this evening

gsalaman commented 3 years ago

I was thinking more branching based on where a component was in its lifecycle rather than per component. Here's more detail:

The main branch contains the latest/greatest stable code. We try and make it such that main ALWAYS works on the jumbotron...if it breaks, it's #1 prio to fix it.

Now, let's say Jonah is developing minesweeper, Bennett C4, and I'm adding an MQTT-button-emulator to the framework. We all create development branches for those actives based on Main/latest. Once your piece is "ready", you do a pull request back into main, and let the rest of the team know.

So, let's say in the above example, minesweeper is ready before C4 and the emulator. Jonah pushes into main, but then Bennett and I have a choice: do we merge the changes from Main into our dev branches, or do we wait until our "feature" is ready? (the answer to that really depends on the situation).

How do we define when a piece is "ready" to be merged back into main? Code review required? What level of test is required? Or do we go "wild west" and just let it go whenever?

In any event, all this probably needs a live discussion between the three of us...

jlefkoff commented 3 years ago

That sounds good! I don't think the production branch should be created yet as I need to finish up the launching framework.

On the code review question. I think as long as we can get someone to try the new game QA style and the stress test works, it gets merged to prod. We can just clone the branches on the pi to test.

gsalaman commented 3 years ago

Yup...agree a good starting point is where we have the launching framework with the top two screens activating TTT.

Hmmm....and that brings up a cool idea. Ready for some more SW engineering definitions? Unit test is typically done by the developer (or team) that wrote the code in question.
Then, in production, there can be many other levels of "production" or "QA" test. There is value in having someone who doesn't know how the code works "beat on it"...no assumptions based on internals.

So with that, there are different "formality" sweet spots, from:

jlefkoff commented 3 years ago

Discussion has been had.