💊 #1 - The Power of Pipeline as Code for a Mobile Developer

This is a series of little articles in form of pills that I mention episodes of my professional day by day.

Man, come here, please
For sure. What’s up?
The pipeline configuration needs to be updated. One argument is missing for the correct execution of the command that generates the splitted APK’s.
Hum, ok. Please, fix yourself. I’m going to have a lunch.

That happened. It’s real. And it was great that happened. Let me see: it’s a mobile developer that will works with a delivery pipeline. And he will be enable to do that.

Firstly, because the pipeline will be described inside the target solution. That is, the mobile developer can change the pipeline if he wants. This because the pipeline will be described as code. A pipeline as code, like this way:

version: 2
jobs:
build:
working_directory: ~/code
docker:
- image: circleci/android:api-27-alpha
environment:
JVM_OPTS: -Xmx3200m
steps:
- checkout
- run:
name: Download Dependencies
command: ./gradlew androidDependencies
- run:
name: Run Code Static Analysis
command: ./gradlew :dashboard-data:ktlint lintDevDebug
- run:
name: Run Unit Tests
command: ./gradlew :dashboard-data:testDebugUnitTest :feature-dashboard:testDebugUnitTest
- run:
name: Generate Code Coverage
command: ./gradlew jacocoFullTestReport
- run:
name: Send Code Coverage to Codecov
command: bash <(curl -s https://codecov.io/bash)
- run:
name: Install graphviz
command: sudo apt-get update; sudo apt-get install graphviz
- run:
name: Generate Project Dependency Graph
command: ./gradlew projectDependencyGraphGenerator
- run:
name: Generate release APK's
command: ./gradlew assembleRelease
- store_artifacts:
path: installed/build/reports
destination: reports/lint
- store_artifacts:
path: project-dependency-graph
destination: reports/project-dependency-graph
- store_test_results:
path: dashboard-data/build/test-results
- store_test_results:
path: feature-dashboard/build/test-results

Developers talk technically through code. The responsible by pipeline is talking with the developer by code. They understand each other. The team work did not stop.

So, the mobile developer put the missing argument that is necessary in script of this way:

./gradlew assembleRelease -PsplitApk

Commit, push, run CI (continuous integration) stages and… GOOD! There are the splitted APK’s, with the updated script in version control repository together with the target solution:

Pipeline together with the main solution
If you liked, clap on the left side. This helps in spreading the article to other readers. 👏

Another benefits…

  • The pipeline is part of the solution as a whole, not a separate entity with no connection
  • To track the changes on pipeline during the timeline
  • The pipeline can be shared among several solutions, because it is a common file.