Branch Development Structure

[pstrauch]

We should discuss a workflow structure with branches to secure our main branch. I list three possibilities here:

Production + Feature

• One long-term production branch (main) featuring the latest working and tested version.
• Short-term feature branches for implementing new features.

Workflow

After implementation, the feature is tested on the feature branch. If successful, a pull request is opened for adding the feature to the production branch.

Arguments

• Pro: Straight forward, simple overview, less overhead
• Con: Difficult to test and resolve conflicts between multiple features, thus more prone to errors in the production branch. For resolving conflicts, new features must be pushed to main first before being considered by other features.

Production + Development + Feature

• Long-term production branch (main) featuring the latest working and tested version.
• Long-term development branch featuring new implemented features.
• Short-term feature branches for implementing new features.

Workflow

After implementation, basic tests are run on the feature branch. If successful, a pull request is opened for adding the feature to the development branch. On the development branch, multiple features can be tested simultaneously to check for conflicts. If changes are needed, they can either be done directly on the development branch or on a separate branch for resolving conflicts. After a new package including multiple features is tested successfully, it can be added to the production branch.

Arguments

• Pro: Allows for checking and resolving conflicts apart from the production branch. Thus, a more robust and clearer production branch results. Generally requires more testing or review for a new feature.
• Con: Slightly bigger overhead because new features must first be pulled onto the development branch before being considered for the main branch.

Production + Stage + Development + Feature

• Long-term production branch (main) featuring the latest working and tested version.
• Long-term stage branch featuring the latest tested packages.
• Long-term development branch featuring new implemented features.
• Short-term feature branches for implementing new features.

Workflow

Similar to Production+Development+Feature. Conflicts between multiple features can be resolved on the development branch which can be based on fake data and systems. Once it is safe to assume that no relevant structures are broken, these changes are added to the staging branch, where recent packages can be tested on the real system. Finally, packages can then be released to the production branch.

Arguments

• Pro: Allows for checking and resolving conflicts apart from the production branch and relevant data. Requires a lot of testing, thus making the production branch most secure. Testing on the development branch doesn't break relevant data or the real system. The staging branch allows for checking the final integration to the real system.

• Con: Biggest overhead. Having a development and staging branch present might be unnecessary in our context. Too much testing and reviews required in the context of our small workforce, thus hindering fast progress.

[pstrauch]

We leave it at Production + Feature for the moment until we have the basic architecture set up.

From then on, we might use a development branch in between. We deploy the development branch to production by including proper documentation for the new features. Deploying releases to the production branch also helps to get a good high level overview of what features are present in the latest working version.

Note: Development branch should use default merging, whilst production branch should use something similar to sqash-merge.