intive Argentina Blog

Manejo de ambientes con archivos de propiedades

Diferentes ambientes

Algo habitual en el desarrollo de software es el uso de diferentes ambientes. Vamos a suponer que en nuestro proyecto actual tenemos los siguientes:

  • dev
  • test
  • stage
  • production

Para cada uno de ellos, disponemos de una misma variable a la que queremos asignarle información diferente. Algunos ejemplos pueden ser: una ip o un subdominio de un servidor, una api key de algún servicio externo o algún flag que identifique si queremos loguear o hacer un tracking de algo en particular.

En aplicaciones Android contamos con los conocidos Flavours para resolver esta situación. Pero en esta oportunidad nos vamos a focalizar en una alternativa diferente. Hablamos del uso de archivos de propiedades, con un poco de ayuda de Gradle y Groovy.

¿Cómo funcionan los archivos de propiedades?

Lo primero a considerar es que estos archivos de propiedades se alojarán en un repositorio diferente al que contiene el código de nuestra aplicación.

La excepción que confirma la regla se puede dar si tenemos un ambiente de test, en el caso de que se necesite que los desarrolladores lo puedan compilar, pero sin necesidad de que nadie les pase un archivo de configuración (directamente descargando el código de la aplicación). En ese caso podremos dejar solamente ese archivo subido al repositorio del código.

¿Cómo implementamos esta solución?

Para implementar esta alternativa podemos proceder de la siguiente manera:

1)Extraer todas las configuraciones a un archivo properties que podemos colocar en el root del proyecto.

Screen Shot 2017-07-26 at 11.55.17 AM

Por ejemplo, supongamos que tenemos los siguientes datos que queremos que cambien con cada ambiente:

Para poder cargar dichos valores necesitamos un archivo de propiedades base. Llamémoslo conf.properties. Este archivo va a contener lo siguiente:

2)Ahora, para poder hacer que nuestra aplicación use esos valores tenemos que ir al build.gradle. Dependiendo de cómo se necesiten los datos, este paso puede variar ligeramente. En el ejemplo lo hacemos en el defaultConfig, pero se puede usar dentro de buildTypes o donde se necesite:

3) Ahora solo resta crear un archivo diferente para cada ambiente. De esta manera obtendremos cuatro archivos en total, con las variantes de los datos que queramos para cada uno de ellos.

4) Desde nuestro código vamos a poder acceder a los datos usando BuildConfig.IP o BuildConfig.LOG_ON.

Integrando con Jenkins

En la configuración de Jenkins se puede hacer que, al compilar, el ambiente utilice un archivo específico. En caso de que los ambientes estén en diferentes branches también podemos lograr que traiga el branch del repositorio que aloja al archivo necesario.

Suponiendo que los archivos se llaman igual pero están en diferentes branches se puede hacer algo parecido a lo siguiente:

Así copiamos el archivo en el directorio, para que el servidor de integración continua los levante al compilar.

De esta forma, al compilar se puede seguir usando el mismo comando para todos los ambientes. Por ejemplo, para Debug:

O para releases:

¿Por qué usar estos archivos de propiedades?

Configurar nuestros ambientes con estos archivos nos va a permitir lo siguiente:

  • Como los archivos van a estar en un repositorio diferente, sólo las personas/servidores de integración continua necesarias van a tener acceso a datos sensibles de ambientes protegidos. Por ejemplo, evitaremos que cualquier usuario con acceso al código pueda crear una aplicación apuntando directamente al ambiente de producción. Así, en caso de tener que compartir el repositorio de la aplicación para un code review, gente ajena al proyecto no tendría acceso a información sensible sobre el mismo.
  • Nuestro servidor de integración continua va a tener las configuraciones necesarias para compilar las apk en los diferentes ambientes. De esta forma, nos aseguramos de que las apps siempre se crean desde el mismo ambiente y con la misma configuración, evitando cualquier cambio innecesario que algún desarrollador pueda tener en su equipo local.

En nuestra opinión, los Flavours no deberían usarse salvo en proyectos chicos sin información sensible para proteger. Utilizando archivos de propiedades estamos priorizando la seguridad y la protección de datos sensibles y, al mismo tiempo, nos aseguramos de que el proceso de desarrollo fluya. Por eso, en intive-FDV elegimos esta opción para muchos de nuestros proyectos.

Gastón Goncalves

Trabaja en intive – FDV desde 2012. Desde febrero de 2015, es desarrollador  Android e integra dicha brigada. Antes, también en la compañía, fue desarrollador de Drools y Java EE. Es alumno de la carrera de Ingeniería en Informática de la Universidad de Buenos Aires. En la UBA, también fue docente ayudante de la materia Algoritmos y Programación II de la Facultad de Ingeniería.

1 comentario