Novato Ant: ¿Qué files registrar para SVN si usas Jenkins y Ant?

Estoy intentando configurar la automation de compilation (con Jenkins) para mi aplicación de Android usando Ant (proyecto no Maven).

La máquina que ejecuta Jenkins verifica el código periódicamente desde SVN y ejecuta el file build.xml en la raíz de origen. Ahora hay un file de configuration (digamos Config.java), que define los parameters del entorno prod / staging / dev; que estoy generando usando el command "ant config_dev" etc. Pero solo habría una versión de este file en SVN.

Mi consulta es qué versión (dev / prod / stage) debería estar en SVN? Si pongo la versión Dev en SVN, ¿cómo puedo entregar comstackciones Prod y Staging? Por ahora, supongo que necesito 2 tareas de Jenkins (1 para Staging y 1 para Prod) y en cada tarea, después de verificar el código, debería volver a generar el file de configuration correspondiente (ejecutando ant config_prod o ant config_stg); y luego build

¿Es esta la manera recomendada? ¿Cómo ejecuto la tarea "ant config_prod" justo después de verificar el código y ejecutar una compilation?

No agregue files de configuration y files generados al control de versiones.

¿Cómo ejecuto la tarea "ant config_prod" justo después de verificar el código y ejecutar una compilation?

Una tarea de Jenkins puede tener varios pasos de compilation, por lo que es fácil:

  1. Paso 1: ant config_prod
  2. Paso 2: ant (para ejecutar la tarea Ant pnetworkingeterminada, o bien, ant whatever_your_build_task_is )

cómo entregar comstackciones Prod y Staging?

Tienes varias opciones.

  1. Use una única tarea de Jenkins para entregar todo, con muchos pasos de compilation, por ejemplo:

    1. ant config_dev
    2. ant build_dev
    3. ant deploy_dev
    4. ant config_staging
    5. ant build_staging
    6. ant deploy_staging
  2. Use tareas Jenkins separadas para cada env. Tienes al less dos opciones:

    1. Cada tarea de Jenkins tiene su espacio de trabajo independiente (el pnetworkingeterminado). Esto es un poco derrochador, porque cada uno necesitará una verificación limpia del código fuente. Por el lado positivo, cada tarea será independiente, por lo que pueden ejecutarse en paralelo si es necesario.

    2. Todas las tareas de Jenkins comparten su espacio de trabajo: usted anula la configuration pnetworkingeterminada para especificar un espacio de trabajo, y usted especifica lo mismo para todos. Esto ahorrará espacio en disco, pero tendrá que tener cuidado para evitar ejecutarlos en paralelo, ya que puede get comstackciones rotas o algo peor.

Si el file de configuration java es generado por el process de compilation, no lo verificaría para el control de fuente en absoluto.

En cuanto a la generación de configuraciones diferentes en diferentes entornos, tendría diferentes trabajos de Jenkins que tienen arguments de línea de command de ant ligeramente diferentes. La construcción de ant puede generar diferentes configuraciones basadas en los arguments de línea de command dados.

PERO dado que esta es una aplicación de Android, lo que realmente haría es generar una única APK que tenga una configuration de configuration oculta para cambiar los entornos. De esta forma, sabrá que está enviando el binary idéntico al que está probando.

No uso Jenkins, pero en mi entorno, solo las fonts y todos los files de configuration entran en control de fuente. Mi process de compilation extrae / comstack la configuration correcta en function del entorno en el que estoy creando y despliega eso con los otros artefactos construidos. Luego etiqueto mis fonts para el entorno que acaba de buildse, así que puedo rebuild exactamente lo mismo más adelante.