Skip to content

Gitlab Auto Devops for Android

DevOps (short for Developer and Operations) is a term coined to describe the approach of using tools, metrics and processes to help your team deliver high quality experiences — using automation to minimize mistakes and maximize efficiency in product delivery. It is focused on enabling developers to use and manage software operations processes and infrastructure without needing a separate operations team. “DevOps culture” is here to make your lives easier and ensure that your users get the highest quality product in the users’ hands and speed up your development process.

What is AutoDevOps?

As enterprises begin to embrace the benefits of DevOps to improve their application workflow, challenges still exist in the development process that prevent a streamlined workflow between developers and operations. In this interview, Sid Sijbrandij, CEO and co-founder at GitLab, shares insight on the company’s plans to offer an automated approach to DevOps, and shares solutions for enterprises who are interested in adopting DevOps as part of their business strategy.

Traditional AutoDevops

DevOps process is very important for us as it help us to improve operations and development processes. Fews months ago Gitlab introduced very cool feature with us which is known as Auto Devops. It will reduce so many efforts of process management. As per current standards we are following below mentioned steps.

1 Gitlab push

2 Jenkins hook integration

3 SonarQube code check

4 Upload build on server and so on.

But through the help of this Auto DevOps process, we never need to follow above steps. Only git push event will create build for us with functional, unit testing. Even with help of this we can publish our app on Google Play store/ Apple APP store.


Create your project as you are creating for Android. Then do the push event.

  1. As we are using then we have to know few git commands very well.
git init 
 git commit -m “<add desired message>”

git merge brancha branchb

git push origin master 
  • Create  .gitlab-ci.yml file and add codes 
image: openjdk:8-jdk variables: ANDROID_COMPILE_SDK: "25" ANDROID_BUILD_TOOLS: "24.0.0" ANDROID_SDK_TOOLS: "24.4.1" before_script: - apt-get --quiet update --yes - apt-get --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 - wget --quiet --output-document=android-sdk.tgz${ANDROID_SDK_TOOLS}-linux.tgz - tar --extract --gzip --file=android-sdk.tgz - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter android-${ANDROID_COMPILE_SDK} - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter platform-tools - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter build-tools-${ANDROID_BUILD_TOOLS} - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-android-m2repository - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-google_play_services - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-m2repository - export ANDROID_HOME=$PWD/android-sdk-linux - export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/ - chmod +x ./gradlew stages: - build - test build: stage: build script: - ./gradlew assembleDebug artifacts: paths: - app/build/outputs/ unitTests: stage: test script: - ./gradlew test functionalTests: stage: test script: - wget --quiet --output-document=android-wait-for-emulator - chmod +x android-wait-for-emulator - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter sys-img-x86-google_apis-${ANDROID_COMPILE_SDK} - echo no | android-sdk-linux/tools/android create avd -n test -t android-${ANDROID_COMPILE_SDK} --abi google_apis/x86 - android-sdk-linux/tools/emulator64-x86 -avd test -no-window -no-audio & - ./android-wait-for-emulator - adb shell input keyevent 82 - ./gradlew cAT

A little bit explanation about file.

Running unit tests

  stage: test
    - ./gradlew test

This defines a job called unitTests that runs during the test stage. Nothing crazy here – we’re just running unit tests.

Building the app

  stage: build
    - ./gradlew assembleDebug
    - app/build/outputs/

This defines our first job, called build. It’s the only job in the build stage. It just builds the debug version of the app and makes the outputs of the build available for download via the artifacts field.

Run your new CI setup

After you’ve added your new .gitlab-ci.yml file to the root of your directory, just push your changes and off you go! You can see your running builds in the Pipelines tab of your project. You can even watch your build execute live and see the runner’s output, allowing you to debug problems easily.

After your build is done, you can retrieve your build artifacts:

  • First, click on your completed build:


So, there you have it! You now know how to create a GitLab CI config that will ensure your app:

  • Compiles
  • Passes unit tests
  • Passes functional tests

And allows you to access your build artifacts (like your APK) afterwards.


  • It will reduce hook events.
  • Developer no need to worry about code unit testing. It will help on single place and seniors can add their commits easily.
  • Pipeline structure is very simple.
  • Developer will get pipeline failure email automatically.
  • Will reduce Traditional Devops processing steps.


  • We need to purchase Google cloud kubernetes, if we want to add cluster in it.

Previous article

Flutter Vs ReactNative

Next article

Unbelievable but true! Buy Google Pixel 3 With in 12K From Flipkart, here’s how

Join the discussion

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: