Intive Blog

Management of environments with properties files

Different environments

Something very commonplace in software development is the use of different environments. Let’s suppose that in our present project we have the following:

  • dev
  • test
  • stage
  • production

For each of these, we have the same variable which we want to assign different information to. Some examples can be: one ip or subdomain on a server, an api key of some external server or some flag that identifies if we can log in or perform a tracking of something in particular.

On Android applications we have the well-known Flavours to overcome this situation. But now we will focus on a different alternative. We are speaking about properties files, with a little help from Gradle and Groovy.

How do these properties files work?

The first thing to bear in mind is that these properties files will be hosted in a repository different from the one that has our application code.

The exception that confirms the rule can appear if we have a testing environment, in case you need developers be able to compile it without the need of anyone providing them with a configuration file, (directly by downloading the application code). In that case we can leave only that file uploaded to the code repository.

How can we implement this solution?

In order to implement this alternative we can proceed as follows:

1) Extract configuration in a properties file which can be placed in the root of the project.

Screen Shot 2017-07-26 at 11.55.17 AM

For instance, let’s suppose we have the following data we want to change for each environment:

We then need a file of base properties to be able to load those values. Let’s call it This file will have the following:

2) Now, we should go to build.gradle in order for the application to use those values. Depending on how these data are needed, this stage might have small variations. We are doing it on the defaultConfig in the following example, although it can also be used within buildTypes or wherever it is needed.

3) Now we just have to create a different file for each environment. We will consequently have four files all in all, with the data variation we want for each.

4) We can access data through BuildConfig.IP or BuildConfig.LOG_ON from our code.


In the Jenkins configuration you can make the environment, while compiling, use a specific file. In case that the environments are on different branches, we can also make it retrieve the branch from the repository that is hosting the requested file.

Assuming the fact that the files have the same name but are on different branches, something similar to the following can be carried out:

We copy then the file to the directory, so that the server of continuous integration uploads them while compiling.

Thus, the same command can be used while compiling all environments. For instance, to DeBug:

or for releases:

Why use these properties files?

By setting up our environments with these files we will achieve the following:

  • Since all files will be in a different repository, only the people/servers of continuous integration needed will have access to confidential data of protected environments. For example, we will prevent any user with access to the code from creating an application aimed directly at the production environment. Consequently, in case the repository has to be shared for a code review, outsiders to the project would not have access to confidential information about it.
  • Our server of continuous integration will have the necessary configurations to compile the apk’s in the different environments. In this way, we make sure the apps are always created from the same environment and with the same configuration, avoiding any unnecessary change that some developer might have in his/her local team.

For us, Flavours should not be used except for small projects which have no confidential data to protect. By using properties files we are prioritizing the security and protection of confidential data and, at the same time, we are ensuring that the process of development flows. That is why, in intive-FDV we choose this option for our projects.

Gastón Goncalves

He has been with intive – FDV since 2012. As of February 2015, he has been an Android developer. Previously he was a Drools and Java EE developer. He is currently studying I.T. engineering at Universidad de Buenos Aires (UBA). He was also a teacher at UBA, teaching Algorithms and Programming II in the Engineering department.

Add comment