Distribute Unclear Responsibilities in The Team With Automation
Having a lot of developers in a single repo often creates bottlenecks for processes like PR review and automation. Carrying out all these operations manually is troublesome and has a high margin of error. For this, we try to develop most of the processes we use internally by automating them. In a moment, we will explain in detail how some of these processes work.
PR Reviewer Selection Process
One of the essential processes in the Trendyol iOS team is to identify the developers who will review the PRs. Since there are too many PRs, it is not possible for everyone to look at every PR. That’s why we decided to determine the developers who will review the PRs with a specific ruleset. The iOS team is divided into many small teams within itself. Still, since the whole project proceeds with the same codebase, people in different teams can review the PRs of other groups without being alienated.
People who will review the PR are randomly selected among all developers, two from the PR owner’s team and four from the other groups, and everyone’s responsibility pre-determined. Anyone can be a reviewer and check the PR than these six people. When a new PR is opened, people added to the previous PR will not be added again unless all developers are added to a PR.
New Candidate Case Reviewer Selection Process
One of the essential stages in new candidate interviews is to examine the candidate's case and give the necessary feedback. Six people are randomly selected among the developers to determine who will review the case. When a new candidate project arrives, people added to the previous candidate projects will not be added again until all developers are added to any candidate project.
As with the developers, random assignments are made to the QAs to review the incoming cases in the new candidate interviews. As a difference in QA teams, the selection is made among all QA friends in both Android and iOS groups.
Vacation Mode
The biggest problem when choosing developers and QAs for PR or case reviews is that they can still be selected as reviewers when they are on leave. It can cause a bottleneck, especially in summer. To solve this problem, we added vacation mode to our automation processes. When the developer or QA on leave enables the vacation mode, he/she is not assigned as a reviewer to any pr or case.
After returning from leave, they disable vacation mode and can be selected as a reviewer.
Add A New User
Friends who have just joined the team must be included in the system to be assigned to the pr and case review processes. We do this with automation that listens to Slack channels. In order for the automation processes to understand the newly joined user name, whether he is a developer or a QA, it is sufficient to execute the comment below where the role and the name of the team he/she joined needs to be specified.
Used Technologies
There are several different technologies used in the back for the management of the whole process.
We keep users’ information in tables on PostgreSQL.
We use the Fluent framework provided by Vapor to access this data and use it wherever we want.
Fluent supports adding, updating, filtering, and deleting database operations using Swift language.
As previously explained, we run the remaining parts of the automation processes through a bot called Skynet.
As a result, we achieved automating our reviewer selection process efficiently. If you have any questions, feel free. Thanks for reading.
