How to use different sets of properties files on the build server and on the development machines?

Question

I have a web application. I am setting up CI for this.

We did not use the build tool (neither Ant nor Maven), but created assemblies using the IDE. Now I am working on an Ant script that will be used by our build system.

There are several property files that must have different property values ​​when the project is built on the build server, but not on local machines.

What are the common approaches to solving this situation?

If we used Maven, I would probably use different profiles, but we have Ant.

One of the possible solutions that I see is to create a root folder for all sets of properties files and save each set in a separate subfolder (see diagram below).

/profiles /dev1 prop1.properties prop2.properties /dev2 prop1.properties prop2.properties /build-server prop1.properties prop2.properties /webapp /WEB-INF 

Then during Ant build, we can copy the correct set to the right place. But there may be a problem with the build using the IDE, as we did (since the property files are no longer stored in the appropriate location in the src folder).

Are there any other approaches?

Answer 1

If I understand you, you create separate ears / wars / banks for each environment on your continuous build server. It is right?

I have two ways to handle this: Smart Way and Dumb Way:

Smart way

The smart way is to configure the application server (JBoss, Weblogic, etc.) to find the desired properties file external to jar / ear / wars installed on the application server. This way you create one set of beat / ear / war, and it works everywhere. In addition, you are doing something very, very important: you call Finger O 'Blame elsewhere.

If the properties files are packaged as part of the jar / ear / war and something on the server has changed, you will get the fault because your build was bad. Of course, you had no way of knowing that they changed the environment, but you installed this bad build file on a production server.

However, if the properties are stored outside the build artifact, then this is the command responsible for setting up servers that do not work.

In fact, it is much easier for the team responsible for setting up the application server to deal with this problem. They know what has changed, and they can update the properties file to reflect this change. Not only that, but you only need to create and distribute one set of artifacts. You don’t need to worry about whether the new environment is configured if something changes in the old environment. In fact, changes can be easily implemented without forcing you to create a new version.

---

Stupid way

We were able to do something Smart Way in my last company. In my current company, we are doing Dumb Way things. Properties are built into our build artifact, and there is no easy way to change it.

I split each set of property files with a suffix instead of different directories (e.g. build.properties.dev1, build.properties.dev2, etc.). We placed the property files in one directory.

When I do the assembly, I use the AntContrib <for> task to cycle the build process several times, each time with a different property file. Then I create an artifact for each set of property files. I use the suffix in the properties file as the folder names in my target directory, where I store inline artifacts. Thus, each assembly creates all artifacts for the entire environment.

Thus, if the artifact worked in a dev environment, it will work in QA and Production. The only problem is that I store 5-10 times the number of artifacts on my Jenkins server, so I need 5-10 times more disk space.

By the way, as long as I can define <fileset> to find the property files, I can use the <for> task, so you can use different directories. And you can use <basename> to delete directory names.