Automating our workflow at Trendyol Android Team #2
In previous blog post of this series, we talked about why we need to automate our workflow and we also explained our scheduled and event-triggered jobs, briefly. If you haven’t read it yet, you can take a look at the post below as it would be helpful for you to understand the concept of this series.
This article mainly focuses on the automated parts in our JIRA pipeline. I will try to explain how we implemented automation project and which APIs are used in this implementation. I will also give some code snippets to clarify our methods.
As we mentioned earlier, we use JIRA for issue tracking, Stash for repository management and Slack for team communication. Therefore, our automation workflow has a frequent communication with these APIs. We also use Ktor framework for the necessary API calls. Ktor is developed in Kotlin and it is a convenient and readable framework. When considering a team consists of Kotlin developers, we thought these advantages can give us the speed we need.
Let’s take a look at what we have done so far and dive into implementation details. Basically, we will focus on items below:
- Moving tickets to ready for QA column
- Notifying team when a regression issue is created
- Building UAT package and notifying product owners
Moving Tickets to Ready For QA Column
We have several columns in JIRA due to our needs and two of them are code review and ready for QA. Every ticket needs to be moved to code review column when corresponding feature development is finished. After it meets the required conditions, related ticket are moved to ready for QA column. As you can guess, sometimes moving ticket to the ready for QA can be missed, so we thought it would be better to automize this step.
For this purpose, we have a classed named PRChecker which checks all pull requests, and moves tickets which are ready to be tested to the ready for QA column. This checker is triggered in every 5 minutes and follows the steps below.
- It gets open pull requests list by using Stash API.
- It filters list as it contains pull requests which has no open tasks, 4 approves and no needs work votes and getIssueKey from branch name. You can find detail information about our git workflow in blog post below.
- Ticket in some columns such as blocked or ready for UAT shouldn’t be moved therefore it checks whether a ticket needs to be moved. JIRA API is used to achieve this.
- Lastly, related tickets are moved to ready for QA column by using JIRA API and transition ids.
To sum up, our flow is implemented as :
Notifying Team When A Regression Issue is Created
In our team, development continues concurrently with regression tests but whenever an issue is opened during regression we focus on this bug immediately. Therefore it is really important for us to be notified when a new bug arrives. We thought if we automate this step we can save time, do not miss a new issue and we can also take an action quickly.
To achieve this, we listen a webhook in JIRA. This webhook is triggered if an issue with regression label is created. We also have a class named RegressionIssueNotifier which listens this webhook and send a message with related issue id and link to our Slack channel. You can find implementation details below.
- First JIRA webhook is created with necessary conditions.
- Created webhook with given path is listened in our Application class and it triggers the related method for notifying Slack channel.
- Finally, RegressionIssueNotifier sends a message which contains issue details to the Slack channel by using Slack API.
Building UAT Package and Notifying Product Owners
In mobile team, UAT is performed by related product owners. Before this feature, we need to inform product owners ourselves and they need to build the package by themselves. If we forget to communicate with product owners or they miss to check ready for UAT column, we can face some delay while performing tests.
As a result of this, whenever a ticket moves to ready for UAT column, we trigger a Jenkins jobs which build both prod and test packages. After the completion of builds, this job sends packages and inform all product owners via Slack.We have a UatPackageBuilder class which listens JIRA webhook and perform the action by following the steps below.
- As in ready for QA notifier, JIRA webhook is created.
- Jenkins job to start build from given branch is created. This job also send both test and prod APKs to Slack thread and notify product owners by executing the pipeline steps below.
- Application class listens webhook with given path and it starts the UAT package build process.
- UatPackageBuilder class fetch all pull requests and get branch name from given issue key.
- Before starting the build, we send an information message which includes branch name to our Slack channel.
- After Slack message, we start related build by sending post request to our Jenkins url. As it seen below, we need time stamp in this method to be able send a message in a Slack thread from Jenkins job.
- Briefly, startUatPackageBuild method looks like:
In this blog post I mentioned automated parts in our JIRA pipeline by explaining our motivation and implementation details. Thank you for reading so far and I hope you find something useful for your automation process. Feel free to leave a comment if you have any questions or comments!
