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.
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.
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.
git init git commit -m “<add desired message>” git merge brancha branchb git push origin master
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 https://dl.google.com/android/android-sdk_r${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 https://raw.githubusercontent.com/travis-ci/travis-cookbooks/0f497eb71291b52a703143c5cd63a217c8766dc9/community-cookbooks/android-sdk/files/default/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.
unitTests: stage: test script: - ./gradlew test
This defines a job called unitTests that runs during the test stage. Nothing crazy here – we’re just running unit tests.
build: stage: build script: - ./gradlew assembleDebug artifacts: paths: - 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.
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:
So, there you have it! You now know how to create a GitLab CI config that will ensure your app:
And allows you to access your build artifacts (like your APK) afterwards.