You could also try using different maven profiles to build a specific artifact suitable for tests, but that's not recommended. You should test a version of your system that is as close as possible to the one in production.
So, yes, environment variables are the most portable way to do this. A powerful Jenkins plugin to control them is EnvInject. You can define specific variables as simple key-value pairs that will be injected in the build process.
Edit
Since you're using Spring Batch, you're able to setup database connection using xml files or programmatic configuration. Configuration files support only system properties, so you would do:
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="url" value="${db.url}" />
<property name="username" value="${db.user}" />
<property name="password" value="${db.password}" />
<!-- drivers and other stuff -->
</bean>
For programmatic configuration (which you can see a thorough example here) you may use system properties too:
@Bean
public DataSource someDataSource() throws SQLException {
final SimpleDriverDataSource dataSource = new SimpleDriverDataSource();
dataSource.setUrl(System.getProperty("db.url"));
dataSource.setUsername(System.getProperty("db.user"));
dataSource.setPassword(System.getProperty("db.password"));
// Driver, connection properties, if any, and other stuff
return dataSource;
}
And also environment variables:
dataSource.setUrl(System.getenv("db.url"));
dataSource.setUsername(System.getenv("db.user"));
dataSource.setPassword(System.getenv("db.password"));
You would set environment variables using the EnvInject plugin, but if you use system properties the simplest way to pass them is as command line arguments: java ... -Ddb.url=something -Ddb.user=foo -Ddb.password=bar. Notice, however, that anyone capable of listing that java process will have access to the db credentials. If you stick to properties, you can also pass them using properties files, which Spring seems to support. The problem is you would have to maintain separate configuration files for each environment, something I believe adds to much overhead to a build process that could be simpler.
