Skip to main content
avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
December 12, 2023
Solved

Dealing with server specific files and GIT

  • December 12, 2023
  • 4 replies
  • 1616 views

This is a generic problem but one that I face now and then moving code changes through GIT and wanted to get your thoughts. I have some integrations where properties files store the connection information to that other database. That database will be different for Dev/Test and production so that file needs to have the right connection information. Just recently, I have changes to my security labels and am calling out a group for Agreement Managers. That org tied to that group is different in my Dev server and my production server. Obviously, this needs to be changed during deployment. 

As I moved toward more automated deployment methods, how based do we handle these server specific file alterations? I am considering moving many of these specific parameters to an .xconf file and out of the GIT repo. This will take some refactoring. The securityLabelsConfiguration.xml is another story. Do I just have to create a special deployment task which is to update all of these known places where Dev/Test differ from production? Seems like I would keep adding and adding conditions to this task. Thoughts?

    Best answer by avillanueva

    I think I am going to leverage the xconf files to handle this. I was reading I am violating a best practice not to put connection information in the source repository. I can implement a project that removes all of this and puts it in the wt.properties files via a special, server specific .xconf file. Passwords should be added to encrypted properties (https://www.ptc.com/en/support/article/CS255640?source=search). 

    So, how this might work is that I have a dev, test and prod specific xconf file that is mapped respectively into the site.xconf. Any customization that needs properties that I typically would put in the package as a .properties file, gets moved there. I think this can work, project for co-ops this year.  Thanks for all the replies and suggestions. 

    4 replies

    R
    rhart16-Pearl
    16-Pearl
    December 12, 2023

    Perhaps an option would be to maintain separate branches of the source control for the dev/test environments, or maybe modifying the hosts file could work to redirect to another IP while using the same hostname/server in the xconf. I think it’s possible in some cases to replace the connection info in the xconf with environment variables.

    A
    AndyHermanson14-Alexandrite
    14-Alexandrite
    December 12, 2023

    We use templating and json file. Each Environment is its own branch. The json file stores the server specific info and then is placed into the template files based on the branch.

    R
    RandyJones20-Turquoise
    20-Turquoise
    December 12, 2023

    I am checking for the hostname and setting up properties based on that:

    String hostName = WTProperties.getLocalProperties().getProperty("wt.rmi.server.hostname");
if ("<hostNameOfProductionServer>".equals(hostName)) {
	dbPropertiesKey = dbPropertiesKeyProduction;
} else {
	// We have a development host
	dbPropertiesKey = dbPropertiesKeyDevelopment;
}

     

    I also have my own "rehosting/cloning" script in which I "rehost" other scenarios - this includes running sql queries to update vaulting hosts and other tables in the db. However this also needs updated when I add new scenarios. You could possible have a sql query that runs during "rehosting" that updates the membershiplink table and changes the ida3b5 of the appropriate row.

     

    One goal is to design your dev environment(s) to be as hostname independent as possible. This is where something like docker --network-alias comes in handy.

    avillanueva
    23-Emerald I
    avillanueva23-Emerald IAuthorAnswer
    23-Emerald I
    January 18, 2024

    I think I am going to leverage the xconf files to handle this. I was reading I am violating a best practice not to put connection information in the source repository. I can implement a project that removes all of this and puts it in the wt.properties files via a special, server specific .xconf file. Passwords should be added to encrypted properties (https://www.ptc.com/en/support/article/CS255640?source=search). 

    So, how this might work is that I have a dev, test and prod specific xconf file that is mapped respectively into the site.xconf. Any customization that needs properties that I typically would put in the package as a .properties file, gets moved there. I think this can work, project for co-ops this year.  Thanks for all the replies and suggestions. 

    Terms & ConditionsCookie settingsAccessibility statement