We're in process of defining a workflow for mobile builds across multiple developers. We've only had one until recently, so we didn't have to worry too much about tracking simultaneous feature builds for QA (we use gitflow).

1) Versioning

Builds for the apple and android stores require versions. But, features built for QA won't have an assigned version yet, since we don't know what release it will be in. We are thinking of just using the current version in production, and using build counts to differentiate builds. Is there a best practice for tracking builds in Testflight / Google Play only targeted for internal test?

2) Tracking Builds in JIRA

With multiple builds in the store for testing, we need to tag our JIRA tickets with the associated build in the store. We're going to do this manually, but I'm not sure the best way to do that is. And, if we wanted to build in some automation, what would that look like?

1 Answer 1


The answer will vary depend on the CI/CD tooling you are using.

If you are planning on using Atlassian's CI/CD tool Bamboo, you could use the Bamboo variable ${bamboo.buildNumber} which ties the build number of Bamboo to your version number. You can have a task that will adjust the version based on this variable. Bamboo integrates with Jira so that you can see the builds and deployments directly within Jira. There is also Git so you could see the commits that went into the deployment. This effectively would automate the second requirement you listed.

There are plugins available for Jira that will integrate with other CI/CD toolsets (e.g. Jenkins, CircleCI), and the idea would be the same: let the CI/CD server automate the versioning for you.

  • if I have version 3.1.6 in production (ios and android), and I have two feature branches pushed today, what version/versioncode/buildcount would you use for these two features?
    – gdbj
    Commented Jul 29, 2019 at 19:29
  • Again it depends on the CI/CD service and your workflow. The two features if merged to a mainline "Develop/Integration/Master" branch could trigger the build and then the versions would be 3.1.7 and 3.1.8 for the two features. That way you know that the build 8 and build 9 correspond to the newly merged feature set. The next feature set merged would have build number 9 and set the version to 3.1.9. Commented Jul 29, 2019 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.