Difference between revisions of "Branching strategy"
Nullkiller (talk | contribs) (Created page with "This article suggests a branching strategy and an approach to produce stable releases while allowing to have not very stable develop branch. The main problem we encountered mo...") |
Nullkiller (talk | contribs) |
||
| Line 1: | Line 1: | ||
This article suggests a branching strategy and an approach to produce stable releases while allowing to have not very stable develop branch. The main problem we encountered moving towards release 1.0 was features/new-terrains branch which was separated from develop until the release date. This caused a lot of conflicts and awkwardness and blocked decent testing of final codebase because some code was in develop and some in feature branch. We agreed to have releases twice a year after release 1.0 so we need a different branching strategy now. | This article suggests a branching strategy and an approach to produce stable releases while allowing to have not very stable develop branch. The main problem we encountered moving towards release 1.0 was features/new-terrains branch which was separated from develop until the release date. This caused a lot of conflicts and awkwardness and blocked decent testing of final codebase because some code was in develop and some in feature branch. We agreed to have releases twice a year after release 1.0 so we need a different branching strategy now. | ||
| − | Develop and Feature branches | + | |
| + | == Develop and Feature branches == | ||
| + | |||
In order to make develop developers branch we should stop regular users from playing daily builds unless they want to be beta testers and are prepared to bugs! So we can freely accept new features to develop without some beta testing phase and not being afraid that we hurt gameplay with some bugs and affect our community in a bad way. We should avoid big PRs if we want to spot some bugs and code smells during code review. But some big features which can not be made in a single PR could be implemented in a feature branch. All such branches should have their names starting from features/* are will be automatically protected by branching policy - PRs will require approval from somebody else from the dev team. Also such branches will have own daily builds. As soon as the feature is ready and more or less stable - we can merge it to develop. | In order to make develop developers branch we should stop regular users from playing daily builds unless they want to be beta testers and are prepared to bugs! So we can freely accept new features to develop without some beta testing phase and not being afraid that we hurt gameplay with some bugs and affect our community in a bad way. We should avoid big PRs if we want to spot some bugs and code smells during code review. But some big features which can not be made in a single PR could be implemented in a feature branch. All such branches should have their names starting from features/* are will be automatically protected by branching policy - PRs will require approval from somebody else from the dev team. Also such branches will have own daily builds. As soon as the feature is ready and more or less stable - we can merge it to develop. | ||
| − | Code freeze | + | == Code freeze == |
| + | |||
In order to deliver our new features from develop to end users we need a stabilization phase. Lets have some code freeze and encourage our dev team to fix bugs! Nobody likes this but it is needed. I suggest to start such phase 1 month before planned release date. All features could be implemented in feature branches and can be merged after release. All bug fixes target develop. As soon as we ready - we make a release, upload builds to github, add a release tag and can break develop again. | In order to deliver our new features from develop to end users we need a stabilization phase. Lets have some code freeze and encourage our dev team to fix bugs! Nobody likes this but it is needed. I suggest to start such phase 1 month before planned release date. All features could be implemented in feature branches and can be merged after release. All bug fixes target develop. As soon as we ready - we make a release, upload builds to github, add a release tag and can break develop again. | ||
Revision as of 10:49, 17 September 2022
This article suggests a branching strategy and an approach to produce stable releases while allowing to have not very stable develop branch. The main problem we encountered moving towards release 1.0 was features/new-terrains branch which was separated from develop until the release date. This caused a lot of conflicts and awkwardness and blocked decent testing of final codebase because some code was in develop and some in feature branch. We agreed to have releases twice a year after release 1.0 so we need a different branching strategy now.
Develop and Feature branches
In order to make develop developers branch we should stop regular users from playing daily builds unless they want to be beta testers and are prepared to bugs! So we can freely accept new features to develop without some beta testing phase and not being afraid that we hurt gameplay with some bugs and affect our community in a bad way. We should avoid big PRs if we want to spot some bugs and code smells during code review. But some big features which can not be made in a single PR could be implemented in a feature branch. All such branches should have their names starting from features/* are will be automatically protected by branching policy - PRs will require approval from somebody else from the dev team. Also such branches will have own daily builds. As soon as the feature is ready and more or less stable - we can merge it to develop.
Code freeze
In order to deliver our new features from develop to end users we need a stabilization phase. Lets have some code freeze and encourage our dev team to fix bugs! Nobody likes this but it is needed. I suggest to start such phase 1 month before planned release date. All features could be implemented in feature branches and can be merged after release. All bug fixes target develop. As soon as we ready - we make a release, upload builds to github, add a release tag and can break develop again.
