Agreements
Ferdy Rodriguez edited this page Mar 17, 2022
·
4 revisions
After Release beta 2.0.0 and next sprint we will be working with the full gitflow, this means:
- The develop branch should be used as the main one for working with jira issues instead of branches like “2.0.0_beta”.
- Pushes to develop/master/release_branch should not happen, instead we should open a Pull request.
- When the development of the sprint is finished (after 3 weeks) a branch will be created (ej: 2.0.1_beta) this branch will be freezed and Nancy will perform regression on it. In this branch “2.0.1_beta” only issues fixed reported by nancy will be merged.
- If someone is developing something during regression it should be merged in develop, this means that will be included in the next sprint, not the current one.
- When the regressions are finished and nancy gives the okay, we have to merge the release branch (“2.0.1_beta”) to master and tag it, then merge to develop as well.
- If a version has been released to play store and some important bugs have been found in PROD we might need to create a hotfix. In this case, we open a branch from master called ex: “2.0.2_hotfix_beta”. We fix the issues and merge them in this branch (keep in mind that CI should give green for every issue) then the hotfix branch will be merge in develop too.
- PR with translations are opened automatically pointing to develop. This is fine until we create a release/sprint branch that is frozen for regression. If during regression a PR is opened with a translation pointing to develop we’ll ignore it and wait for the PR to master. Doing this we make sure to not include other things that have been merged to develop.
- Right now: Builds are trigger everyTime a developer open a PR and pushes (PR, Beta/Develop, Master)
- Here you can find a list of tasks that want to be automated with CI (feel free to add more) https://docs.google.com/document/d/1NOFXq6H963Himop1rXluyqOOyCwIH0rbZux5yT3cyhg/edit?usp=sharing
- Careful about full automatic translation between java/kotlin from the IDE. Most of the time the kotlin code just looks like java and not “kotlin”, also it does not take advantage of “?” features or many others with more potential (lambdas, lists, etc..).
- We’ve agreed to a 1 month sprint (3 development weeks with 1 regression + issues). This could change over time until we find the best sprint/timing for us.
- Every Friday (perhaps Wednesday) Nancy will get a debug APK on her mail. (This could change too).
- After the development of the sprint finishes, the sdk submodule of the app will point to a frozen branch that was generated by the sdk team
- During development we should never point to a commit sdk module unstable, if the last one is not stable we should point to the previous one.
- All new development should have its own unit tests.
- If the unit test class does not exist, the developer will carry out any refactor needed to create and initialize any test for the desired class.
- Code reviewers should watch over any missing unit tests before approving a pull request.
- We agree that when a Jira issue is moved to "Needs Check" column and important changes to the code were made to fix it. The developer that made the change will re-request code review in the original Pull Request that was created when the Jira issue is move to the "In Review" column.