standalone.xml version control best practices

[Valerii Pekarskyi]

Hi Team,

In my current project we deal with several environments (production, staging, development, one or more feature-specific) that have slightly different configuration and struggle keeping them in sync. Would anyone describe best practices of how it is easier to modify the configuration?

For now we have several folders with different standalone.xml versions, and every development change in one of them should be promoted to all the others. This process is quite error-prone, so I am looking for better ways to do this.

Currently environment configurations differ with the system-properties, datasource configurations, pool sizes, slightly different infinispan cache configs. Maybe we can have the list of CLI commands to modify default configuration instead. It will complicate the application startup as we'd have to start empty Wildfly first, apply configuration changes, and then deploy application archive. Again, the list of CLI commands will be split into common and environment-specific, easy to lose a change in one of the files...

Thanks,

Valerii

[Emmanuel Hugonnet]

You might want to take a look at the git integration, having all your files living in a git repository with history and  branches support.

https://www.wildfly.org/news/2018/09/28/Git-History/

Emmanuel

> --
> You received this message because you are subscribed to the Google Groups "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/wildfly/1009518f-2973-464a-9b79-e26ad4642db6n%40googlegroups.com
> <https://groups.google.com/d/msgid/wildfly/1009518f-2973-464a-9b79-e26ad4642db6n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Sebastian Brack]

Way before Git integration was a thing in Wildfly, we used a different approach.

We use an object model + generator approach.

We have a Java object model of all the config settings that change between stages / environments.

Then we have one Java class implementing the concrete settings for each logical system. (this could also be a database)

Then we use Apache Freemarker as template engine, and together with the object model we can generate standalone.xml files (and/or standalone.conf.bat) for each logical system.

On top there is some code to start and stop services and you can deploy your config changes in realtime to any running system

(check if cluster partners are running, stop service, deploy config change, start service, wait for successful deploy, repeat for every node in the cluster)

It was actually very little investment, like 100hours and this was all up and running. It works for 12 years now.

Regards,

Sebastian

[Emmanuel Hugonnet]

For customization you can use YAML to overlay your standard configuration with your specifics.
https://www.wildfly.org/news/2022/04/26/YAML-configuration-extension/

Emmanuel

[Valerii Pekarskyi]

>  https://www.wildfly.org/news/2022/04/26/YAML-configuration-extension/

That is a thing I was looking for! Pity it is available with Wildfly 26 or newer. Better plan upgrading soon :)