Lifecycle of the Trendyol Android App
At Trendyol, we practice “Agile” methodologies and use “Git Workflow” to smooth the process of our work. It’s quite important for us that every piece of work we take on, lives a healthy process from design until the end users’ hands. In this article we wanted to share some of our experiences and practices that we benefit from.
Workflow
Release early, release often
Trendyol mobile team decided that 1-week sprints are ideal for our pace after trying different options. Because 1-week sprint provides more flexibility to PO. Our Product Owner prepares the sprint beforehand and creates the next sprint. If we have jobs with a large scale in the next sprint we have a grooming meeting before planning and discuss the details of the jobs. During planning the team determines the story points and shake hands.
After the planning, the sprint starts. Developers assign themselves to the job they select and move it from ”Ready for Dev” to “In Dev”. From this point until the job is moved to “Ready for QA” the developer is responsible for the job. After creating a branch that follows the conventions of the team and completing the requirements of the job, developer creates a pull request and moves the job to “Code Review”. Anyone from the team can track the job via the JIRA-Stash integration.
In order for the job to move another step to “Ready For QA”, two other developers from the team should review and approve the pull request. Any job that has two approves automatically moves to “Ready for QA”. At this point the job is in the hands of the QA team. QA assigns the job they selected to themselves and move to “In QA”. When the testing of the job is finished, job is moved to “Ready for UAT” at which the job is in the hands of the PO and the Design Team for the “User Acceptance Test”. When the issues pointed out by QA, PO and the Design Team is resolved the job is moved to “Done” and the related branch is merged into develop by the QA.
Branch Naming and Git Workflow
In the mobile team we work with two main branches: develop and master. Develop is the branch, as the name suggests, where all the development takes place and has the most up-to-date version of our codebase. Master is the branch that holds the current version from the store. For every job a new feature branch is created from develop. We name our branches in line with the following convention:
- <JIRA code>/<Description> (eg: ANDDEV-2297/basketSupplierTaxKep)
Other than develop, master and feature branches we also have DEV_PROCESS and RC(Release Candidate) branches for separation of different flows. DEV_PROCESS branches are for jobs that have a large scope and needs more than one sprint to be fully implemented. RC branches are when we need to freeze the current state of the develop branch, to run regression tests and to release.
To sum up:
- Feature Branches are for jobs with relatively small scopes and they can be merged in to develop with the QA’s approval.
- DEV_PROCESS branches are for jobs with a large scope which we create feature branches from. These feature branches are tested and merged back into the DEV_PROCESS branch and later when the process is completed the DEV_PROCESS branch is merged into develop. This allows us to continue working on other small features while implementing big features.
- Develop contains the most recent version of our codebase. RC and Feature Branches are created from develop.
- Master contains the released and working version of the codebase. After the release is adopted by %100 of our user base, the related RC branch will be merged into master to keep master updated.
- RC contains the code that will be released and is ready to be subjected to regression.
Release Process
As mentioned above, when we finish the releaseable issues and issues can be “Done” and merge them, we create an RC branch from develop with the naming convention below:
- <version.code>-rc (eg. 3.14.0-rc)
Then we start the regression process where we test the entire app’s functionality. Finally when the regression bugs are fixed in the RC, we create a release APK from the RC.
We release our versions to our users in a staged rollout. We start with a %2 or %5 rate and then gradually increase this rate while solving any problems happening.
We have shared a repository about Android guidelines on Trendyol Android app.
We hope we helped you with this article, if you have other questions, please let us know! If you have liked this article, don’t forget to 👏 it. Thanks!
