Automating semantic versioning model in mobile releases

Mobile applications have become increasingly important in business, transforming both the business and software development practices. 

In this new dynamic and agile reality it’s vital that development teams obtain constant customer feedback so that they can operate effectively. The practice of continuous delivery can help because software releases are made frequently and with minor changes — this helps derisk deployment. With this approach, the software is tested constantly and issues can be detected and fixed quickly.

One example of this type of automation was in a critical project that we worked on for a client. It was a mobile framework that was used by a large application to allow the end user to make in-app purchases. That had a very fragile architecture, with no defined code standards, with non-effective unit tests (since they do not guarantee the main business logic of the application) and without any automated processes.

In this post we will demonstrate how we automated the distribution process using semantic versioning (SemVer) model. The initiative bought the team more time to invest in other improvements actions, such as: architecture evolution, bug fixes and unit testing.

Starting out with SemVer

The SemVer specification is a versioning model for software development projects, authored by Tom Preston, co-founder of GitHub. Using its set of rules makes it possible to distribute a project code in different stages and the relevant dev teams can choose the version that best suits them (this is what most of the libraries and frameworks do). Breaking changes, bug fixes or new features can be easily identified just by looking at the increased version number.

"Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next." 

In order to standardize the customer project infrastructure, we chose the GitLab CI system as a continuous integration and delivery platform, because it made it possible to automate the application distribution to  framework consumers, also known as: developers.

The GitLab CI pipeline was configured to have four stages: build, lint, test and release. Once the first three stages are successfully executed, the fourth stage, 'release', is made available to be launched. The following image displays the project pipeline screen:

Figure 1: Part of the GitLab CI interface, displaying the pipeline and the release jobs that can be executed manually

In a perfect world, we would have only one job that would receive the release type as a parameter that we’d like to perform. Unfortunately, the GitLab CI tool doesn’t allow parameters to be passed when executing a specific job. That said, at the time of writing, there’s an open ticket to add this feature at some point. 

For this reason we had to configure three different types of jobs (a flow of tasks to be executed), one for each type of distribution. Following the specification of SemVer: 

releaseAndBumpMajor: increments the 'major' value of the version (x.0.0) and reset the 'minor' and 'patch';
releaseAndBumpMinor: increments the 'minor' value of the version (5.x.0) and clears the 'patch';
releaseAndBumpPatch: increments the version 's patch value (5.0.x);

In order to define the three distribution jobs through GitLab CI, it was needed to configure the ".gitlab-ci.yml" file, which is responsible for defining the pipeline settings.
 

releaseAndBumpPatch:
 when: manual
 stage: release
 script:
   - fastlane release semverBumpType:patch
 only:
   - master

 

releaseAndBumpMinor:
 when: manual
 stage: release
 script:
   - fastlane release semverBumpType:minor
 only:
   - master

eleaseAndBumpMajor:
 when: manual
 stage: release
 script:
   - fastlane release semverBumpType:major only:
   - master

  The 'when: manual' configuration allows us to launch the job with just one click through the GitLab CI interface (image 01). The 'only: master' setting defines that the job will be available when a commit is coming from the master branch, and the 'script: fastlane release ...' setting is responsible for incrementing and distributing the new version to the consumers.

We chose to use Fastlane in our project to make test automation and deploy easier. It also has an action called increment_version_number, which can pass the key 'bump_type' with the values of 'major', 'minor' or 'patch'. This action is already based on the SemVer model and makes it very simple to increment the version of your project. But, it’s also possible to use any other type of technique or even write a custom script that does this same type of work.

The Fastlane versioning action is only available for the iOS platform. However, this operation can be implemented with a shell script or even a Gradle task for Android applications. As you can see in the Gradle script below:
 

import java.util.regex.Pattern

task bumpSemver << {
  if (type != "major" && type != "minor" && type != "patch") {
    println "SemVer type param should be passed. (major, minor or patch)"
    return
  }

  def propsFile = file("sdk/build.gradle")
  def propsText = propsFile.getText()
  def patternVersionNumber = Pattern.compile(versionPropertyKey + "(\s?)=(\s?)"(\d+)\.(\d+)\.(\d+)"")
  def matcherVersionNumber = patternVersionNumber.matcher(propsText)
  matcherVersionNumber.find()

  def major = Integer.parseInt(matcherVersionNumber.group(3))
  def minor = Integer.parseInt(matcherVersionNumber.group(4))
  def patch = Integer.parseInt(matcherVersionNumber.group(5))

  println "VERSION=" + major + "." + minor + "." + patch

  switch (type) {
    case "major":
      major++
      minor = 0
      patch = 0
      break
    case "minor":
      minor++
      patch = 0
      break
    case "patch":
      patch++
      break
    default:
      println "SemVer type should be passed: major, minor or patch"
      break
  }

  propsText = matcherVersionNumber.replaceAll(versionPropertyKey + " = "" + major + "." + minor + "." + patch + """)
  propsFile.write(propsText)

  println "BUMPED VERSION=" + major + "." + minor + "." + patch
}

You must also change the build settings file by adding the current APP_VERSION extra property of the application:
 

  APP_VERSION = "1.0.1"
}

android {
  buildToolsVersion APP_VERSION

  defaultConfig {
    versionName APP_VERSION
  }
}

When executed the script gets the current version of the project through the APP_VERSION property and increment it according to the selected SemVer specification.

Part of the Fastfile file is presented below where the release lane (distribution action) is defined, which is executed by the previous defined jobs in the file ".gitlab-ci.yml" (Image 01). It receives the type of version (major / minor / patch) that we want to increment and distribute.
 

lane :release do |options|
   
# Increments the version according the passed type (major, minor or patch)

# iOS release
increment_version_number(bump_type: options[:semverBumpType])

# Android release
sh "../gradlew bumpSemver -Ptype=#{options[:senverBumpType]} -PversionPropertyKey=APP_VERSION"

# Gets the version number for possible automations
version = get_version_number(xcodeproj: "SDK.xcodeproj")

# Other automated operations

end

Also, you can align with your team other actions that need to be automated in your release process and add them to the location pointed out by the comment: "Other automated operations." Some interesting examples are: updating the changelog file, creating a Git tag for the commit, updating the project .podspec file, updating the remote repository with these new changes, etc. 

But don't forget to automate the most important operation, that’s the one responsible for distributing your software to Google Play or App Store.

Through this article, we have shown how it is possible to generate three different types of automated and versioned distributions. We hope this tip may have been useful for you and would allow for a more frequent distribution of software, with the benefits of versioning the SemVer model covers.