Answers: <p>The answer will vary depend on the CI/CD tooling you are using.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-07-29T19:29:28.573Z
Answers: 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?
Answers: gdbj
Answers: CC BY-SA 4.0
Answers: 2019-07-29T19:36:25.623Z
Answers: 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.
Answers: Wesley Rolnick
Answers: CC BY-SA 4.0
Answers: 2019-07-29T18:49:10.510Z
Answers: 2019-07-29T18:49:10.510Z
Answers: Wesley Rolnick
Body: <p>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).</p>
  
  <p>1) Versioning</p>
  
  <p>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?</p>
  
  <p>2) Tracking Builds in JIRA</p>
  
  <p>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?</p>
  
Tags: <continuous-integration><jira><ios>
Title: Mobile CI: Versioning and Tracking Builds in JIRA
UserDisplayName: gdbj
ThreadText: # Mobile CI: Versioning and Tracking Builds in JIRA
  
  (Asked by: username_0 on 2019-07-29)
  
  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?
  
  **Tags:** continuous-integration, jira, ios
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-07-29. Score: 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.
  
  > **Comments:**
  > **username_0**: 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?  
  > **username_1**: 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.  
  
  ---
  
  