Maven, Jenkins - how to build project to different test environments?

筅森魡賤 提交于 2019-12-05 05:15:38

I wouldn't include any properties in the POM but would use an external property file per environment instead, at least then you wouldn't need to touch the POM when properties change.

In your POM specify a profile which references a property file with your properties in:

<profiles>
    <profile>
        <id>staging</id>
        <properties>
            <app.config>/your/path/to/app.staging.properties</app.config>
        </properties>
    </profile>
</profile>

Then you can pass this into your Surefire configuration:

<plugins>
    <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
            <systemPropertyVariables>
                <appConfig>${app.config}</appConfig>
            </systemPropertyVariables>
        </configuration>
    </plugin>
</plugins>

From within you tests you can then load the contents of the property file, e.g.:

final String appConfigPath = System.getProperty("appConfig");
// Load properties etc...

Actually, you could actually take this one step further... dump the Maven profiles completely and just specify -DappConfig=/your/path/to/app.staging.properties in you Jenkins build configuration.

You can setup maven profiles, and choose which one is active using -P flag

Why not use the Maven build profiles, since you can specify <properties> per profile to specify different build hosts etc. Just do

$ mvn -Pstaging

(say) to enable the staging profile.

See the Sonatype manual on Build Profiles for much more info.

Here I use bash scripts to deploy the Jenkins built artifact to Glassfish.

sudo /usr/share/glassfish3/glassfish/bin/asadmin --user admin --passwordfile /root/.asadminpass undeploy PROJECT_NAME
sudo /usr/share/glassfish3/glassfish/bin/asadmin --user admin --passwordfile /root/.asadminpass deploy $WORKSPACE/PROJECT_NAME/target/PROJECT_NAME.war

Do NOT use Maven Build Profiles for this!

It forces you to actually change your build for different environments.

Instead make your tests, and probably your application configurable. The basic idea would be to read the configuration details (e.g. database urls) from some system properties. Which in turn can easily be specified in Jenkins Job configurations

For more complex scenarios you can specify classes to be used for a give purpose from system properties, for example if you want a MockedImplementation for Dev environment and the real thing in QA.

If you happen to use Spring, have a look at Spring Profiles, which support this kind of stuff very well.

If you only need this in tests, you should be able to encapsulate this kind of stuff in JUnit Rules.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!