Automating our workflow at Trendyol Android Team #1

In this article I’d like to talk about our scheduled or event-triggered jobs we made to keep things organized, fast and less error-prone. Our team has almost doubled its size over the last year and so is the product management team. With this growth a lot of context-switch and complexity came into our lives. And this led to forgotten or wrong actions on our workflow. So we felt the need to automate the actions we could to keep our to-do lists shorter. But before I’d like to recommend two pieces from my colleagues for you to get a better understanding about our workflow and the tools I am about to talk about.

Lifecycle of the Trendyol Android App

Branch Management in Trendyol Android Team

Desired outcome

I also want to mention that we use JIRA, Bitbucket Server and Slack for organizing our tasks, communication and code management. So if you are using these products as well, maybe there could be a couple of practices you could adopt to apply in your organization.

Keeping the build status ready on Bitbucket

We have a couple of constraints to merge a new feature. And one of these are Build Status. And we want to keep these build statuses ready as we don’t want to wait when we’re about to merge a new feature branch.

A look at one of our PR’s commits. Notice Builds column on right side

Build statuses are tied with Commit ID and you could mark one with Bitbucket REST API documented here.

So this is an event-triggered job. What basically happens is when a developer pushes a commit, a Webhook is invoked on our Bitbucket triggering our Jenkins job to run Unit Tests and mark the build status. You could get info on webhooks here as they are really useful and you could do a lot of things with them.

Notifying the author when the PR is reviewed or peers when created

Actually this one is provided by Bitbucket itself by e-mail but let’s admit we could get lost in those since there could be many of them. And we could miss important mails in that e-mail flood about PRs. So what we did was turning off the mailing feature of Bitbucket. Instead we used slack which is far more snappy and noticeable. If a PR is created, reviewers get notified on Slack via DM. Same on the author side, any PR action sends a DM on Slack to author. We used users.lookupByEmail, conversations.open and chat.postMessage for this one.

When someone else creates a new Pull request

When someone else comments on your PR

Keeping the PR source branches up to date

Earlier, I mentioned that we don’t want to wait when we’re about to merge a new feature. Develop branch gets new commits constantly right? And every open PR feature branch falls behind but we want them to be ahead of develop. So we made another event-triggered job to keep these branches up to date. We used a Pull request merge triggered Webhook for this one. Every time it is invoked a list of PRs are fetched from here. For each PR source branch it pulls from develop and pushes it if there are no conflicts.

Notifying the QA and keeping JIRA tickets up-to-date

We have a Ready for QA column on our JIRA board and we want our tickets to be on this column as soon as they are ready. Constraints for this column are;

• There are no open tasks on PR
• At least 4 approve is given by peers
• Unit tests are OK and last commit’s Build Status is marked as Success
• There are no Needs Work mark on PR

This one is a scheduled job and gets invoked every 5 minutes. It fetches open PRs and checks the constraints mentioned above. If it is eligible for testing, it moves the associated JIRA ticket with this one.

Wrapping up

We know that some of these practices could be accomplished with plugins. But we wanted to extend and modify as we wish, so we invested on our very own custom app. We hooked up all of these webhooks with a Ktor app since its easier to develop with a gem like Kotlin. Maybe we could open source it somewhere near future.

How it performs at early stages. Credits to https://twitter.com/Colinoscopy/status/1255890780641689601

There are a couple of more automated jobs like these, but this is going to be a series. So you’ll be seeing them on the next one. We’re getting lazier every day, coming up with new ideas to automate stuff and developing these are actually fun so there will be more.

Pitching ideas or commenting on existing practices are welcome. Feel free to reach me out if you have any bumps implementing these as well.

Thanks for reading!