Ant newbie : What files to check-in to SVN if using Jenkins and Ant?

Question

I am trying to setup build automation (with Jenkins) for my Android app using Ant (non-Maven project).

The machine running Jenkins checks out the code periodically from SVN and runs the build.xml file in the source root. Now there is a configuration file (say Config.java), which defines the prod/staging/dev environment parameters; which I am generating using the command "ant config_dev" etc. But there would be only one version of this file in SVN.

My query is what version (dev/prod/stage) should be in SVN ? If I put Dev version in SVN, then how to deliver Prod and Staging builds ? For now I am guessing I need 2 Jenkins tasks (1 for Staging and 1 for Prod) and in each task, after checking out the code, I should re-generate the corresponding config file (by running ant config_prod or ant config_stg); and then build.

Is this the recommended way ? How do I run the task "ant config_prod" just after checking out the code and running a build ?

Answer 1

Don't add config files and generated files to version control.

How do I run the task "ant config_prod" just after checking out the code and running a build ?

A Jenkins task can have multiple build steps, so this is easy:

1. Step 1: ant config_prod
2. Step 2: ant (to run the default Ant task, or else ant whatever_your_build_task_is)

how to deliver Prod and Staging builds ?

You have several options.

1. Use a single Jenkins task to deliver everything, with many build steps, for example:

   1. ant config_dev
   2. ant build_dev
   3. ant deploy_dev
   4. ant config_staging
   5. ant build_staging
   6. ant deploy_staging
   7. ...

2. Use separate Jenkins tasks for each env. You have at least two options:

   1. Each Jenkins task has its independent workspace (the default). This is a bit wasteful, because each will need a clean checkout of the source code. On the upside, each task will be independent, so they can run in parallel if needed.

   2. All Jenkins tasks share their workspace: you override the default config to specify a workspace, and you specify the same for all. This will save disk space, but you'll have to be careful to avoid running them in parallel, as you can get broken builds or worse.

Answer 2

If the configuration java file is generated by the build process, I would not check it in to source control at all.

As for generating different configs in different environments, I would have different Jenkins jobs that have slightly different ant command line arguments. The ant build can generate different configs based on the command line arguments given.

BUT since this is an Android app, what I would actually do is generate a single APK that has a hidden configuration setting to change environments. That way you know you are shipping the identical binary to the one you are testing.

Answer 3

I don't use Jenkins but in my environment, only sources and all configuration files go into source control. My build process pulls/compiles the correct configuration based on the environment I'm building for and deploys that with the other built artifacts. I then tag my sources for the environment that was just built so I can re-build the exact same thing later.