Automating our workflow at Trendyol Android Team #3
In previous blogposts of this series, we talked about our motivation for automating workflow and we also mention about our scheduled/event triggered jobs and automated parts in our JIRA pipeline. Before diving into the 3rd part I recommend you to take a look at previous parts for detailed information about our process.
In this blogpost I will basically focus on our CD (continuous delivery) process by explaining steps we follow from beginning of RC tests to uploading bundle to Play Store. In the meantime I will try to explain how our internal project maintains this process, what its responsibilities and used technologies.
In previous part, we’ve already mentioned that our automation process depends on the communication between internal projects, Jenkins, Slack, JIRA and Stash. As I am going to explain, Jenkins and Slacks take a major role in management of our deployment process. Let’s take a detailed look at this mechanism and see how it works.
We have a Go project for our deployment process. You can think this project as a bridge between Slack and Jenkins. Basically, it is responsible for their communication and some logical operations. The reason why we developed this project is that we wanted to challenge ourselves. Learning new technology was our main motivation. Although, it is compiled very fast and its ram usage is very low, learning curve and difficulty in onboarding new team members are main problems we face these days.
Our project has a method, which listens Leylek (our Slack app) messages. In other words when we mention Leylek, it takes some actions according to these messages.
After development and feature tests, we start RC test by mentioning Leylek app from Slack like below. And this mention, triggers the project and branch creation starts.
Before explaining the actions this commands cause, I’d like to talk about the file we keep for release status. We have a file named activeRelease which keeps branch name, timestamp and isActive boolean for release status. Branch name keeps the last RC branch name and isActive flag shows whether there is an ongoing process. Timestamp is used to send a message to related Slack thread.
When we initiate a new release, first this file is checked and if there is an ongoing release a reply with an error message is sent to Slack thread. Otherwise isActive flag is set true and activeRelease file is updated in both memory and disk, and then Jenkins job is triggered for branch creation.
Firstly, this Jenkins job increments version code if it is required and creates a new RC branch. Slack thread is also notified about the release process.
Secondly, we install internal sharing artifacts and send link to Slack thread. To do this, we use Gradle Play Publisher. It enables us to install internal sharing artifacts and also upload bundle to Play Store. It also has several other features like uploading release notes etc. If you want to get more information about this plugin you can take look at the link below.
Lastly, this uploaded artifact is stored into disk. Thanks to this, we always upload the artifact which QA engineers installed for test. Long time ago, wrong artifact was uploading to the store accidentally, it is noticed in last minute. After this incident, we just want to be extra cautious.
During RC test, if there is any bug we fixed them as developers. After feature tests are completed, our QA engineers update the current artifact from latest branch and uploads it to the internal sharing by @leylek release update command.
When RC test is done, it is time to upload the current artifact to Play Store. QA engineers triggers upload via Slack message. With this message, our project starts a Jenkins job which is responsible for uploading artifact to store.
In this Jenkins job, we publish the bundle by using publishBundle — artifact-dir task of Gradle Play Publisher. And also, publish link is sent to Slack thread as a response. After this, our project updates activeRelease file with new values.
At the end of the pipeline, QA engineers update the release notes and release the latest version in a staged rollout. Then gradually increase the rate while fixing problems on the road. Even if we don’t use Gradle Play Publisher it can be used for release notes, too.
This part of series focuses on steps we follow while submitting Trendyol app to the Google Play Store. If you would like to get more information about our workflow you check the related article below.
Thanks for reading so far and I hope you can find something useful for your own process. Feel free to reach me out for new ideas or comments!
