We can use React native, an open source mobile application framework by Facebook, to develop application for Android, IOS, UWP, and Web. In this post, we will see how we can release a React native Android application to Google play store with custom app signing, custom app version configured from Azure DevOps pipeline build number. Sounds interesting, right?

Prerequisites

1. Make sure you have a React native application. You can follow this doc to create a dummy application.
2. Azure DevOps

Create a dummy android pipeline

Go to Pipelines in Azure DevOps and click on New pipeline, select Azure Devops, select your repository. In the Configure your pipeline section, select Android.

Rename your YAML file and click save. You don’t have to run your pipeline yet.

Application Configuration

Before we create the pipeline, let’s do some configuration in our application.

Update the Gradle file

A gradle file helps us to,

• Add libraries and dependencies
• Define how to build different environments (debug vs. release)
• Sign Android APKs/AABs
• Automate tasks (e.g., tests, publishing, versioning)

Configure the app versioning

By default, the app gets the verson that is mentioned in the app.json file in the root folder. Just like all the other deployments, it is a great idea to have our app version name and app version code configured to the build number and build id from the pipeline. To do that let’s do the changes below in the android\build.gradle file. Remember there is also another build.gradle file in android/app folder. Under the buildscript section, add the below methods.

def getMyVersionCode = { ->
        def code = project.hasProperty('versionCode') ? versionCode.toInteger() : -1
        println "VersionCode is set to $code"
        return code
    }

    def getMyVersionName = { ->
        def name = project.hasProperty('versionName') ? versionName : "1.0"
        println "VersionName is set to $name"
        return name
    }

Update the ext section as below.

ext {
        buildToolsVersion = "35.0.0"
        minSdkVersion = 24
        compileSdkVersion = 35
        targetSdkVersion = 34
        ndkVersion = "26.1.10909125"
        kotlinVersion = "1.9.24"
        versionName = getMyVersionName()
        versionCode = getMyVersionCode()
    }

Below is the full android/build.gradle file content.

buildscript {
    def getMyVersionCode = { ->
        def code = project.hasProperty('versionCode') ? versionCode.toInteger() : -1
        println "VersionCode is set to $code"
        return code
    }

    def getMyVersionName = { ->
        def name = project.hasProperty('versionName') ? versionName : "1.0"
        println "VersionName is set to $name"
        return name
    }
    ext {
        buildToolsVersion = "35.0.0"
        minSdkVersion = 24
        compileSdkVersion = 35
        targetSdkVersion = 34
        ndkVersion = "26.1.10909125"
        kotlinVersion = "1.9.24"
        versionName = getMyVersionName()
        versionCode = getMyVersionCode()
    }
    repositories {
        google()
        mavenCentral()
    }
    dependencies {
        classpath("com.android.tools.build:gradle")
        classpath("com.facebook.react:react-native-gradle-plugin")
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin")
    }
}

apply plugin: "com.facebook.react.rootproject"

Now go to the android\app\build.gradle file and use the new configs there. Under the android section, go to the defaultConfig and add the content below.

versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName

Your final defaultConfig would looks like below.

defaultConfig {
        applicationId "com.yourapplicationid"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode rootProject.ext.versionCode
        versionName rootProject.ext.versionName

        manifestPlaceholders = [
            appAuthRedirectScheme: "com.yourapplicationid"
        ]
    }

Create and upload keystore to the Secure files

By default the app uses debug configuration to sign, you can see this setting signingConfigs.debug in the section buildTypes for release. You can also see that in the both cases it uses the same debug.keystore file to sign, which is not recommended for the production releases. Let’s create a new keystore file for our releases first. Run the command below. To run the keytool command, make sure to insall the Java development kit (JDK). Also make sure to reference the appropriate JDK version in the command.

C:\"Program Files"\Java\jdk-24\bin\keytool -genkeypair -v -keystore yourkey-key.keystore -alias your-alias -keyalg RSA -keysize 2048 -validity 200000

Make sure to give large number as validity in the command as stated in this post.

Validity (years): Set the length of time in years that your key will be valid. Your key should be valid for at least 25 years, so you can sign app updates with the same key through the lifespan of your app.

As we have created the keystore file, let’s save them in a secured place, and good news is that the Azure DevOps already has a place for this.

From Azure DevOps, go the Library under Pipelines, and click on the +Secure file option under under Secure files.

After the secure file is uploaded, it is important to allow permission for our pipeline to use it. Go to the secure file, and click on the Pipeline permissions and then click on the Add pipeline plus icon and select your pipeline.

Configure the keystore password as pipeline variables

Now it is time to create a variable group in Azure DevOps and add the secured variables. Here keyAlias and keystorePassword is the details you had provided when you were creating the keystore.

Update the Signing config for release

Let’s create a release configuration under signingConfigs like below.

release {
            if (project.hasProperty("KEYSTORE_PATH")) {
                storeFile file(KEYSTORE_PATH)
                storePassword KEYSTORE_PASSWORD
                keyAlias KEY_ALIAS
                keyPassword KEY_PASSWORD
            }
        }

From the above code, the variables KEY_PASSWORD, KEY_ALIAS, KEYSTORE_PASSWORD, KEYSTORE_PATH will be set from the pipeline itself. This is to sign the files using our secure file from Azure DevOps.

As there is a separate signingConfig for release, let’s configure that. Update the release section under the buildTypes.

release {
            // Caution! In production, you need to generate your own keystore file.
            // see https://reactnative.dev/docs/signed-apk-android.
            signingConfig signingConfigs.release
            minifyEnabled enableProguardInReleaseBuilds
            // Enables resource shrinking.
            shrinkResources true
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
        }

Make sure to set the minifyEnabled and shrinkResources to true as this will reduce the overall size of your app bundle and time to install the app. You can read more on the app optimization here.

Optional: Increase the memory during the build

You may get the error below when you run your pipeline.

Execution failed for task ‘:app:collectReleaseDependencies’. > Java heap space

To fix this, go to your gradle.properties and update the settings below.

# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
# Default value: -Xmx512m -XX:MaxMetaspaceSize=256m
org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=512m

Azure DevOps YAML

As we have done the configurations, let’s start updating the YAML file by setting a name first.

name: $(date:yyyy).$(Month)$(rev:.r) 

Below is the full YAML file.

# Android
# Build your Android project with Gradle.
# Add steps that test, sign, and distribute the APK, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/android
# https://learn.microsoft.com/en-us/azure/devops/pipelines/ecosystems/android
name: $(date:yyyy).$(Month)$(rev:.r)
trigger:
  - main
  - development

pool:
  vmImage: "macos-latest"

variables:
  - group: GooglePlayStore
  - name: KEYSTORE_FILE_NAME
    value: 'yourapp-gplaystore-key.keystore'

steps:
  - checkout: self
  - task: UseNode@1
    inputs:
      version: "22.x"
    displayName: "Use Node.js 22.x"
  - script: |
      ls -la $(Build.SourcesDirectory)
      ls -la $(Build.SourcesDirectory)/android
    displayName: "List Android Directory"
  - script: |
      npm install
    displayName: "npm install"
  - task: DownloadSecureFile@1
    name: keyStore
    displayName: "Download keystore from secure files"
    inputs:
      secureFile: $(KEYSTORE_FILE_NAME)
  - script: echo $(keyStore.secureFilePath)
    displayName: "Echo Keystore Path"
  - script: |
      ls -la $(Build.SourcesDirectory)/android
      ls -la $(Build.SourcesDirectory)/android/app
    displayName: "List Files"
  - task: Gradle@3
    displayName: "Gradle Build"
    inputs:
      workingDirectory: "$(Build.SourcesDirectory)/android"
      gradleWrapperFile: "android/gradlew"
      gradleOptions: "-Xmx3072m"
      publishJUnitResults: false
      testResultsFiles: "**/TEST-*.xml"
      tasks: "assembleRelease bundleRelease"
      options: "-PversionName=$(Build.BuildNumber) -PversionCode=$(Build.BuildId) -PKEYSTORE_PATH=$(keyStore.secureFilePath) -PKEYSTORE_PASSWORD=$(keystorePassword) -PKEY_ALIAS=$(keyAlias) -PKEY_PASSWORD=$(keyPassword)"
  - task: AndroidSigning@3
    inputs:
      apkFiles: "**/*.apk"
      apksignerKeystoreFile: "$(KEYSTORE_FILE_NAME)"
      apksignerKeystorePassword: "$(keystorePassword)"
      apksignerKeystoreAlias: "$(keyAlias)"
      apksignerKeyPassword: "$(keyPassword)"
      zipalign: false
  - task: CopyFiles@2
    displayName: "Copy APK Files"
    inputs:
      contents: "**/*.apk"
      targetFolder: "$(Build.ArtifactStagingDirectory)"
  - task: CopyFiles@2
    displayName: "Copy AAB App Bundle"
    inputs:
      sourceFolder: "android/app/build/outputs/bundle/release"
      contents: "**/*.aab"
      targetFolder: "$(Build.ArtifactStagingDirectory)/android/app/build/outputs/bundle/release"
  - task: PublishBuildArtifacts@1
    displayName: "Publish artifacts"
    inputs:
      pathToPublish: $(Build.ArtifactStagingDirectory)
      artifactName: yourapp

We use the task DownloadSecureFile@1 to download the keystore file and provide its path in the Gradle@3 task. We set the name to keystore and use the property secureFilePath to get its path.

Note that in Gradle@3 task even though you have set the workingDirectory as $(Build.SourcesDirectory)/android, you will need to se gradleWrapperFile as android/gradlew. Also check the options we pass to that task, that’s how we are setting the variables to the build.gradle files. The task value assembleRelease is to generate the APK file and bundleRelease is to create Android App Bundle (aab) for Google Play Store.

Google Play Integrations

Once the pipeline is run, you should be able to manually download the App bundle file from the artifacts.

You can upload to the Play store console for doing an internal release to test the app internally now. Select your application, click on the Test and release menu and then under Testing, select internal testing. This is where you can create a few internal users and upload your aab file. You can share the invite link with them. Please be noted that your internal tester would need to accept the request on their first visit to install the app. They should also be able to update the application from Play store when you release a new version.

Service account and permission in Google Cloud Console

Unfortunately the doc here and here are outdated and it took a while for me to configure this. You won’t be able to see the Setup and API access menu in https://play.google.com/console/ as Google had moved them to another process. The new steps are,

Create your service account in Google Cloud

1. Go to Google Cloud Console → IAM & Admin → Service Accounts
2. Create a new service account, grant it the Owner role (or at least Project > Editor)
3. Under the service account, add a JSON key and save the downloaded file. Please make sure to download this to a secure place, as this contains your key in it

Invite the service account in Play Console

1. In the Play Console, go to Users and permissions.
2. Click Invite new user.
3. Paste the client_email from your JSON file (e.g. foo@bar.iam.gserviceaccount.com).
4. Assign your service account permissions:
   • Select your app
   • Give at least the permissions below
     • View app information (read-only)
     • Release to production, exclude devices, and use Play App Signing
     • Release apps to testing tracks
5. Send the invite, this will be auto approved

Create Azure DevOps service connection

1. Go to your AZDO project → Project settings → Service connections.
2. Create a New service connection → Google Play.
3. For service account email, use the JSON’s client_email; for private key, paste the entire key (include \n line breaks exactly)
4. Save it with the name yourapp-google-play. Make sure to replace yourapp with your app name.

Update the release YAML with GooglePlayRelease task

The final step in the YAML file is to update it with the GooglePlayRelease task so that we can release app directly from the pipeline.

  - task: GooglePlayRelease@4
    inputs:
      serviceConnection: 'yourapp-google-play'
      applicationId: 'com.yourappid'
      action: 'SingleBundle'
      bundleFile: '$(Build.ArtifactStagingDirectory)/android/app/build/outputs/bundle/release/*.aab'
      track: 'internal'

Finally, run your pipeline and if everything goes well, you should see that your pileline result as below.

You should also be able to see the new version released for your internal test users in Google play console.

You can promote or increase the rollout of your application by following this doc.

About the Author

I am yet another developer who is passionate about writing and sharing knowledge. I have written more than 500 blogs on my blog. If you like this content, consider following me here,

• GitHub
• medium
• Twitter

Your turn. What do you think?

Thanks a lot for reading. Did I miss anything that you may think is needed in this article? Could you find this post useful? Kindly do not forget to share your feedback.

Introduction

I understand that you need to move all of your Azure DevOps Work Items from one of your organization to another. And that is the reason why you are reading this article, no worries, you came to the right place. At the end of this article, I am sure that you will be able to achieve this. In my previous article, I had shown you how you can move your repository from one organization to another, if you have not read it, consider reading it.

Move Work Items to Another DevOps

As I mentioned in my previous post I had already set up a sample project in my source DevOps organization and another in my destination DevOps organization. Then I created a sample user and gave access to both projects.

Check the DevOps Project Process

Now before we start we need to make sure that both of the projects follow the same Process in the DevOps.

Change the Project Process

If the process of the two projects is different, then you will end up in many issues in the publishing steps, thus changing it to one is very important. To change, you need to have certain permissions as mentioned in this post. Once you have enough permission, go to your organization settings and click on the Process menu under Boards.

Now you should be able to select the projects which are assigned to each process, clicking the project number will redirect you to the list.

Now click on the three dots you see near to the project name and then click on the Change button.

Just select the process and click Save. And also make sure that you have enabled all the Backlog Navigation Levels.

You are done!.

Create Query to Get the Work Items

Now let’s say that I have below sample work items, and I need to create a query to get all these work items.

Click on the Queries menu on the left side and then click on the +New Query button. In the Type of Query button, click on the “Tree of work items” if you need the tree structure in the work items otherwise just click on “Flat list of work items”

Change the Type of tree dropdown value to Parent/Child, and then run the query.

Just save the query, we will be using that very soon.

Install the Azure DevOps Office Integration Tool

To download the tool, please visit here. Once you install the same, you should see a Team tab in your Excel, yes, we are going to play with Excel now.

Get Data From Azure DevOps in Excel

Click on the Team button and then New List, you will see an option to select the server, or if you don’t have any you need to add it by clicking the servers button.

Now add both Source and Destination DevOps servers.

Now it is time to connect our Source DevOps server.

Click on the New List under the Team tab, will give you an option to select the query that we created before, just select the same and press Ok.

This will fetch all the work items from your source DevOps.

Click on the Team button, select any columns in the excel sheet, click on the Choose Column. Select All Work Items Types in the dropdown and then move all the columns to the right side.

This will show all the columns in the excel sheet with data. Now it is time to publish these work items to our destination DevOps.

Publish Work Items to Destination DevOps

To do this, open another Excel then click on the New List button under the Team Tab. Now select the destination DevOps and connect. In the next Pop up, select the Input List option.

You will be seeing some columns in the excel sheet now. Click the Team button and then Add Tree Level, this will make sure that we have the tree structure in our DEstination DevOps too.

Please make sure that you are adding as many levels you have in your Source DevOps Excel sheet. In our case, it is 4.

Tree Level

Now click on the Choose Columns and add all the columns as we did with the Source Excel Sheet. Please make sure that both Excel sheet columns are in the same order. You can order the fields in the order you wish. Once both excel sheet has the same order, then select the data from the source and then select the first data cell in the destination excel sheet and then press Enter. This is how the data looks like in the destination Excel.

Please be noted that the above screenshot doesn’t include all the columns. In your case, it should be there in the excel sheet.

Now select any column in the Excel sheet and then click on the Publish button under the Team tab. By chance, if you are getting any errors you may have to manually review the same and assign the right values.

If everything goes well, you should see all your work items in your destination Azure DevOps.

Conclusion

Thanks a lot for reading this article. I hope now you have learned about

• how to use queries in Azure DevOps
• how to use Azure DevOps integration tools for Office
• how to change the project Process
• how to move the work items from one DevOps to another

If you have learned anything else from this article, please let me know in the comment section.

Follow me

If you like this article, consider following me, haha!.

• GitHub
• medium
• Twitter

Your turn. What do you think?

Thanks a lot for reading. Did I miss anything that you may think which is needed in this article? Could you find this post useful? Kindly do not forget to share your feedback.

Kindest Regards
Sibeesh Venu

Introduction

For this topic, I strongly believe that there is no need for an introduction as you already know what is Git and Azure DevOps, and I am guessing that you need to move your codebase or repositories from one of your organization to another. That is the reason why you are here. I believe that there is no direct way of achieving this, there may be some paid tools which do the tricks, but I didn’t want to pay anything for this small requirement. So let’s just see how I achieved this. Trust me this is not a tough task as it sounds.

Background

I was working with a project and my customer wanted to move the repositories to their Azure DevOps from ours. So before I do it directly with their DevOps, I wanted to try this out. So I created my own Azure DevOps and moved a sample repository to there from my company Azure DevOps.

Move Repositories to Another Organization’s DevOps

Add a User to Both Organization

To start doing this process, you should add a user to both projects. I created a sample user (tester@njanorumalayali.com) and assign the contributor access for the two repositories. If you don’t have permission to do so, please contact your project administrator and get it done. Once that is done, you can download all the codes from your Source Organization repository. To do that it is a good idea to use an SSH connection.

Configure SSH Key

To create one Generate the RSA key pair by running the ssh-keygen command.

Update the SSH Key in Source DevOps and Clone the Repository

Now go to your source organization and add the Public Key Data under the SSH public keys section. You can find this public key in .ssh folder.

Let’s add a new SSH key now.

Now we can get the SSH clone URL and clone our repository.

You should get a result as in the preceding image if everything correct.

Check out all the Branches and Tags

Now let us just go inside of the cloned project and make sure all the branches are available by running git branch -a.

Now it is time to check out all the branches locally so that they can be pushed to our new Organization DevOps. This is really important if you need those branches.

Now fetch all of your tags too by running git fetch --tags. Once that is done you can verify once again whether all the branches are downloaded locally or not.

Update the SSH Key in the Destination DevOps

Follow the same procedure as you did for the source DevOps and update the SSH public key there.

Remove Old and Add New Origin

Now comes the important step. Here we are removing the old Origin and add our new Origin so that we can push all our changes including the branches and tags. So we are going to run the below commands one by one.

git remote rm origin
git remote add origin 
git push origin --all
git push --tags

As you can see in the above image, all of our codebases now is been uploaded to the new Azure DevOps. I told you already it is not that hard as it sounds.

One thing to notice here is that the new repository will contain your branch history too.

Conclusion

Thanks a lot for reading this article. I hope now you have learned about

• the basic git commands
• how to configure SSH connection in Azure DevOps
• how to push the repositories to another DevOps

If you have learned anything else from this article, please let me know in the comment section.

Follow me

If you like this article, consider following me, haha!.

• GitHub
• medium
• Twitter

Your turn. What do you think?

Thanks a lot for reading. Did I miss anything that you may think which is needed in this article? Could you find this post useful? Kindly do not forget to share your feedback.

Kindest Regards
Sibeesh Venu