Utilizing Gradle, Jenkins and Slack for better Developer-QA interaction (Part 2)
This is the part 2 of article series. In part 1 we got the idea of whole system and how it will automate the manual tasks. In this article we are going to implement the Stage-1 (Internal-QA) and Stage-2 (External-QA) using J-G-S (Jenkins, Gradle and Slack) technology stack.
So, lets get started…
There are four Build Types with four signing configs. See complete build.gradle here. The build types “internalQA” and “externalQA” are for internal and external testing teams while “release” is for PlayStore. Then there are two custom tasks “internalQADist” and “externalQADist” that will be executed by Jenkins.
Here is the flow diagram of the process for Stage-1 (Internal-QA)
Before going further, please install the necessary 3rd party gradle plugins to fullfill our requirements.
gradle-play-publisher Publish Android apk to Google PlayStore from Gradle
gradle-slack-plugin Send Slack Messages to a Slack Channel via Webhook
Fabric Beta Plugin Distribute Android Apk among testers via Fabric.io
In the diagram, you can see that Gradle (task “internalQADist”) has most of responsibilities in our defined process. Gradle Task will build the project, prepare the apk and will distribute to Fabric Beta/PlayStore as well as send the notification to QA Team via Slack Channel.
That’s why Gradle will be the starting point. Let’s create Gradle task “internalQADist”.
Lets not go into depth of this custom gradle task for the sake of sticking to the point of this article and assume that this task will execute the given tasks in sequence:
1- clean (clean the build directory)
2- assembleInternalQA (prepare the Apk using build type “internalQA”)
3- distribute the apk using build type “internalQA” with crashlytics (Fabric Beta)
Jenkins is the next thing we are going to configure for the build type “internalQA”. The Jenkins Job’s name is let say: “My Project Internal QA”.
In Source Code Management section of this new Jenkins Job, enter the path of your git repository and the credentials (if necessary). As we are going to use git branch “QA” for our internal QA team, we will enter this branch name in “Branches to build” field.
Configure the Build Trigger section to poll the QA branch every minute.
Configure Build section to execute our custom gradle task “internalQADist” which will do all the magic for us.
You can use “Invoke Gradle” option to use Jenkins’s local Gradle installation if your source code does not contain its own Gradle Wrapper.
Click Apply and then click Save Button and your Jenkins Job will start looking for the changes in the git branch QA. Now whenever you will want to hand over the build to internal QA Team, you will just merge your working branch into QA branch. Then this Jenkins Job will detect the changes in QA branch and will automatically execute our custom Gradle Task “internalQADist”. That’s all for our Jenkins.
Lets complete Stage-2 (External-QA)
The Custom Gradle Task and the Jenkins configuration is same as the Stage-1 (Internal-QA) configurations except some values. Here is the Gradle code
As we are going to share the apk with External QA Team only whenever we create a new release branch (e.g: release/1.0.4 or release/2.0.0) that’s why we using the same Jenkins configuration as from Stag-1 Jenkins Job except the branch name and Gradle Task in Build Section. The branch name is not static as it was in case of QA Branch. The branch name for our releases is dynamic so we will be using wildcard in “Brances to build” Field.
In the build section, the gradle task “internalQADist” would be replaced with “externalQADist”.
The Slack Configuration
is the next thing we are going to do and actually its very easy to configure. Each of the event “internalQADist” or “externalQADist” will send a Notification to our Slack Channel with new build information for QA Teams. So just create a new Slack Channel (e.g: #proj-droid-build) and get its WebHook URL (See how to get Webhook for a Slack Channel). Use this Webhook Url in Gradle’s Slack Block, like this
This Slack extension would listen for the tasks ‘crashlyticsUploadDistributionInternalQA’, and ‘crashlyticsUploadDistributionExternalQA’ and whenever these tasks would extecute, the Slack messages would be sent to your Slack Channel with build information. You can see how the title of this message would look like by pasting this title into your slack channel.
*```New Build Available | ${version} (${gitCommitCount()})] ```*https://fabric.io/url/to/myappThat’s all.
Congratulations. You just have automated the deployment process in which whenever you will push changes to QA branch or will create a new release branch at the end of sprint, a new apk will be built and shared with respective QA Team automatically. More importantly, in the end, a slack notification is automatically sent to a Slack Channel to inform the respective QA Team about the new Build with its version code on Fabric Beta.
*Bonus*
You can customize the icon and name (e.g: Fabric Beta) of your Slack WebHook for better visibility n Channel, so that the Slack Message would look like:
