Release process for the cloud

This outlines the release process for Avni cloud

Avni release process

What is the current deployed release?

The current release on production can be identified through the following mechanisms

  1. The latest release notes on avni-product
  2. The latest release blog on the Avni blog
  3. The latest communication via email sent to [email protected] (usually with the subject "Avni Release Announcement")

What is the release we are working on?

On Zenhub, all cards in the "Ready" lane will be marked with the current release.

Release numbering

All versions of end-deployable - avni-client, avni-server, avni-webapp, rules-server, and integration-service are marked with a release number that corresponds to the release on Zenhub, whether they are deployed or not. This makes it easier to understand the right version of the production. For the release, we also mark avni-product with the same release number and provide combined release notes there.

Patch deployments happen from the release branch by increasing the patch version by a number (eg: 3.35.0 if patched will have a version of 3.35.1). We do not perform all the activities for the release of a patch.

Other smaller packages such as avni-models and rules-config have their own release cycles that do not correspond to anything. We use semantic versioning for these packages.

Release preparation

  • Create a new branch and tag all end-deployables. Ensure builds pass and deployment happens on the staging server
# Perform this for all end-deployables
# avni-product, avni-client, avni-server, avni-webapp, rules-server and integration-service
# release-number: 3.36 , tag-number: v3.36.0
git stash
git pull --rebase
git checkout -b <release-number>
git push --set-upstream origin <release-number>
git tag <tag-number>
git push origin --tags
  • Inform the channel about the new branch created
  • Create releases on Github using these tags on all end-deployables.

Deploy to production


  • Find the passing circle-ci job for the tag.
  • Copy the RPM URL built by the circle-ci job (available in the ‘Artifacts’ tab of the ‘build’ job of the ‘test_and_build_and_deploy’ workflow).
  • Deploy the rpm on production
wget <rpm url>
sudo service openchs stop
sudo yum remove avni-server
sudo yum localinstall <downloaded rpm-name>
sudo service openchs start
tail -f /var/log/openchs/chs.log


  • Find the passing circle-ci job for the release tag
  • Approve deployment to production


  • Find the passing circle-ci job for the tag.
  • Approve deployment to production


  • Build the apk
## Create prod apks
versionName=3.5.1 versionCode=30501 make release_prod

## Deploy platform translations
make deploy_platform_translations_live
  • Open the Google Play console
  • Open the Avni app and go to Release Menu -> Testing -> Open Testing
  • Create a new Beta release and upload all four APKs
  • Name the version and provide the release notes
  • Rollout to beta
  • Inform the internal channel, and promote the app to production if everything looks fine


  • Close all cards that are in the "Deploy Ready" lane on Zenhub
  • Publish release for all avniproject repos
    • avni-product
    • avni-client
    • avni-server
    • avni-webapp
    • rules-server and
    • integration-service
  • Create a blog on avni-website with details of the release. Make sure to include relevant documentation links and videos if necessary. This is meant for a non-technical user while the release notes on Github can be for developers and implementers
  • Send an email to [email protected] announcing the release
  • Shutdown the prerelease environment if created
  • Merge the release branch to master