How to track and manage changes to the Windchill installation

[TomU]

I am curious how others track and manage changes to their Windchill installation over it's life, and also how you determine which of those changes are still applicable to the next release.

I already use the wtSafeArea for customizations, and I can look at the list of property changes in the site.xconf file, but it's tough to know if I'm missing other things like modified action models, Apache configuration changes, or even operating system changes.  I try to keep a running log of everything I change, but how do I figure out if I missed something?  I don't see any good way to automatically identify everything that's been changed since Windchill was first installed, especially after multiple in-place point releases and a plethora of CPS updates have been applied.

Once I have managed to identify everything I think was changed, I then have to figure out if the change is still applicable and/or necessary to the next Windchill release.  The only way I know to do this right now is by pounding through each of the properties' xconf files (wt.properties.xconf, db.properties.xconf, etc.) and comparing every changed property.  Of course this does nothing to help me become aware of new properties that might be relevant but didn't even exist before.  There has to be a better way...

How do you track and manage these types of changes in your environment?  How do you determine which ones to carry forward to the next Windchill release?

P.S.  I sure wish all (or at least most) of these changes were stored in the database instead of buried all over the place on disk in different files.  It would make the upgrade process SO much simpler.

[AndyHermanson]

We use Azure DevOps (Git Repo) to manage all of our changes and now have an automated deployment when the Pull Request is completed. Anything that is/can be changed via xconfmanger is in a batch or powershell script that is ran and the propagates the changes. 

Long story, short, we dont make many manual changes to the system anymore once past our dev environment. 

@bcedar can probably go into more detail. 

[bcedar]

We do use Azure Devops, but the important thing is a good source control with a good change management process.
We use Git and Branching along with Pull Requests to manage our changes.

All files that are different from Install, for all systems in our environment (we have 3 dev systems, a test, a user acceptance test, and a production system) are captured in ONE repository.  We use CI/CD logic based on the system that is being deployed to in order to pick/choose/build the files for that system.

We use a combination of system specific files, system specific variable files, and template files.

For a branching strategy, we have 3 types of branches: System Branches, WIP Branches, and Maintenance Branches.  All branches are created from the Default branch (master).  All work is done in WIP branches.  As systems are used to test/run the changes, we make a Pull request, WIP -> System, without deleting the WIP branch.  These Pull Requests are typically peer approved, sometimes analyst approved.  Then, before it makes it to Prod (the default branch), we Pull Request it into a Maintenance Branch. The Pull Request is approved by the system owner and competed by an admin, when the Pull Request completes, the CI/CD pipeline copies the files it needs and builds files from templates, then copies them into the system.

Currently we are using a combination of Azure Devops Pipelines, Powershell, Python, and Jinja2.  I'm currently working on minimizing down to just Powershell, because our IT dept is Windows heavy.  Once my delta between my pipeline changes starts to become minimal, I plan to write a post about it.

In a perfect world, I'd adopt Ansible.  If you are starting from scratch, give Ansible a shot.

Key thing, no matter what you do, DO NOT allow yourself to make changes to you Production system directly.  ALWAYS use your source control.  When you have to troubleshoot and make changes directly to Production (cuz it happens), back update your source right away!

[bcedar]

oh, we break our repo down into specific folders

server_files

report_templates

object_initialization_rules

life_cycle_templates
etc...

Basically, if it needs to be zipped to be imported, it gets its own parent directory, then its children folders are the unzipped contents of the export.

The server_files are organized by full path of their destination in the system.  "C:\program files\something" on the target system becomes "server_files/c/program files/something" in my source.
I'd really like to do more with BAC, but tackling the server_files section is a bit more pressing.

[MikeLockwood]

Hi Tom, really good posting.  Agree very much.

We've been 11.0 for 3 years; preparing to upgrade to 12.0 and have been for a while. The delay is due to a) optimizing all on Amazon, which is very good to do but taking some time b) many file-based customizations that we now have, esp. those for integrating w/other systems.  I'm attaching a spreadsheet of these (partial) in case it helps anyone.

[MikeLockwood]

Attaching another file (just for fun) about the configurations / customizations publishing in general.

[jvonzastrow1]

Hi

It all depend on what kind of change. Changes in .xconf are managed in one xconf file that will distribute to correct places. We also use loadFromFiles where ever possible, ex to load preferences.

We manage all source files in svn, and have all changes done here. So Basic we can install an empty Windchill and deploy all configurations with ant scripts. The result is a empty Windchill with same configuration as production server. Very usefull for test and development on a small server.

Documentation and validation are important.

[fivig]

I also tracked all the Windchill customization/changes in the Excel spreadsheet. Each customization has a dedicated project in GIT For some heavy customizations, I prepared ant/bash script to install/uninstall So during the Upgrade process, I deployed a new version of OOTB Windchill, if necessary update customizations and create a new version of Excel spreadsheet. Also, one interesting thing to track all the changes in Windchill installation using GIT to commit whole Windchill catalog, except vaults, logs, temp... Some useful threads:

• https://community.ptc.com/t5/Windchill/What-is-your-GIT-strategy/m-p/543264
• https://community.ptc.com/t5/Windchill/Windchill-Parallel-Environment/m-p/61563
• https://support.ptc.com/help/wnc/r11.2.1.0/en/index.html#page/Windchill_Help_Center/WCSysAdminQualityAgentWindchillSystemCustomizationsReport.html

[TomU]

There seems to be a common theme of using development tools (git, svn, ant, etc.) to manage Windchill.  The struggle here is that I'm not a developer and have no experience with any of these development tools.  We do not have any developers in house.  I am "the guy".  I install, configure, and manage our Windchill, Creo, and Solidworks installations, as well as install, configure, and manage all of the engineering servers (VMs) that these things run on.  I'm concerned that trying to learn, install and then manage these additional developer tools would become a full time job by itself.  Thoughts???  Is there a "using Windchill with git" guide out there somewhere???

[MikeLockwood]

All changes made via a browser (e.g. OIR's, ACL's, Type and Attribute manager changes, etc.) are stored in the database and come with the database import for both re-hosting and upgrades, so this is covered.

Changes made on the Windchill desktop including property changes, custom states and roles, custom classes, modified .jsp files, etc, etc. have to be managed. For re-hosting using Clone scenario all these come along (although some have to modified on the target at times). This all works well also.

However, the fundamental problem is this.  For upgrades, all changes on the Windchill desktop (customizations) need to be deployed on the target; they are not brought with the database import for upgrade, and cannot be copied from the existing install.  On top of this, one has to carefully manage / examine what might have changed release to release.

A file-based customization that works perfectly say in 11.0, needs to be re-applied, likely by different people, to an 11.1 system, and then an 11.2 system, and then a 12.0 system, and so on thru who knows, release 15.0.  Some customizations require desktop files & commands, along with various actions from a browser, and some require files stored in source control (e.g. SVN).  I'm struggling now with applying all customizations correctly to a 12.0 system in prep for upgrade from 11.0, due to our documentation not being good enough.

[TomU]

---

@MikeLockwood wrote:

However, the fundamental problem is this.  For upgrades, all changes on the Windchill desktop (customizations) need to be deployed on the target; they are not brought with the database import for upgrade, and cannot be copied from the existing install.  On top of this, one has to carefully manage / examine what might have changed release to release.

---

Bingo.  That is exactly where I'm at right now.

The Windchill Systems Customization Report that @fivig mentioned looks pretty slick, but from what I can tell it does not exist in Windchill 11.0.  I think I may try to run it on my new Windchill 12.0 system after making all the changes I think are needed, and then see if it correctly identifies everything I changed.  It will also be interesting to see what it identifies after performing the actual upgrade process.

[fivig]

You can easily use Git by installing client https://git-scm.com/downloads
cd $Windchill_home
git init
git add -A
git commit -m "Base commit"
try to apply any Windchill customization
run: git gui (command should display to you all changes in Windchill home catalog)

But you can run Windchill Comparison utility with any version of Windchill.
To run it without Windchill you have to specify java classpath, from Windchill 11.2+ installation:

WindchillCompareUtility.jar
asm.jar jackson-annotations.jar log4j.jar saxon.jar thingworx-communications-client-java.jar
asm-tree.jar jackson-core.jar mksapi.jar slf4j-api.jar webservices-rt.jar
commons-codec.jar jackson-databind.jar netty-all.jar slf4j-log4j12.jar
commons-io.jar joda-time.jar OracleThinDrivers.jar sqljdbc4.jar
guava.jar json.jar org.eclipse.jgit.jar thingworx-common-java.jar

This is not a recommendation, just my thoughts.

[TomU]

@fivig,

What happens after a CPS installation?  Would git then show tons of stuff as changing?  How do you keep separate things you intended to change vs. what PTC changes?

Are you also using github, or just git by itself?

Thanks.

[fivig]

After CPS "git status" command will show a list of changes in the home catalog.

I used an on-premises GIT repository.

Git repository with separate projects for each customization. If it is possible I made an ANT script to install this customization.

[bcedar]

Initializing Git on the whole of WT_HOME is a big ask of Git, unless you making use of Git_LFS (large file storage).

PTC suggest implementing the wtSafeArea to manage your customizations, then it'll tell you what has changed between patches and upgrades based on what is in ptcOrig

http://support.ptc.com/help/windchill/wnc/r11.1_m020/whc_en/index.html#page/Windchill_Help_Center%2FWCCG_Oview_ManageCust_Intro.html%23

I would do a Git init on wtSafeArea if i do this at all inside of WT_HOME.

Currently we don't, we manage our git outside of WT_HOME and copy into wtSafeArea.  I don't consider anything inside of WT_HOME as "in my control"

[bcedar]

If you can get your company to pay for it... I'd highly suggest taking a Windchill Customization class.  Here's the one we took at our company and it was well worth it.

Since you are just getting started, this is the PERFECT time to establish customization standards and norms.  Get ahead of it, cuz once you start customizing you're going to wish you had figured this out.  You should managing your configurations the same way as you manage your customizations, since the lines blur between the two frequently.

https://www.felcosolutions.com/training
Windchill Customization Course - 2 Days

(i don't work for felcosolutions and am not advocating you use them, just showing what we have done)

[RandyJones]

I also have taken Felco Solutions Windchill Customization course and highly recommend it. This is an excellent course with a plethora of real use case examples. This course integrates coding examples, eclipse ide, and the proper use of the wtSafeArea to manage your customizations.

[TomU]

I actually took the Felco Solutions customization course, and by the time I was done I realized it wasn't for me and any future customizations were going to be outsourced.  I'm not a Java programmer and was pretty lost with all of the interrelated stuff one had to know to be successful.  The amount of time it was going to take to get good at customization was WAY beyond the amount of time I have to devote to it.  My primary job function is to keep Windchill and Creo running, and the user base happy.  I'm never going to get good at customization if I'm only doing it for a few days each year.  There's simply too much one needs to know.  I'm sorting of feeling the same way about GIT and ANT.  Both are developer tools are not very intuitive/useful for those who aren't developers (and have no intention of becoming one).

As far as customization standardization, I get what you're saying but I don't really have any control over that.  I'm at the mercy of however the 3rd party developer chose to construct their add-on.  A few make use of the wtSafeArea, but most are going right into the Codebase.  Some of them are even using their own folder structure completely outside of Windchill.  Everyone is different, which makes managing all of their customizations quite a challenge.

[bcedar]

I see where you're coming from. You absolutely have the right to add "use of wtSafeArea" as a requirement for your work with vendors. They'll get it. Really it's the only way you'll know if a patch will break one of their pieces of work.
If a vendor (or anything) requires you to modify a `$wt_home/` file, be sure to grab a copy of it and paste it into ptcOrig with correct relative pathing as if ptcOrig is $wt_home.
For administration of any servers, I strongly suggest the use of a system management language like Ansible. And this is something to take to your whole IT department. Once everyone starts using the same configuration language and a git workflow, you'll have true change management and cross training opportunities. But I get how that's a big ask. I have a hard time getting many people convinced of this. If I were to stand up an IT department from the ground-up... I'd love this workflow.

git + ansible + ansible tower = configure/manage all the things (servers, network devices, scada devices)...
if it can be shelled into, it can be centrally managed.

[bcedar]

oh, another thing i've learned recently that i wish i knew years ago...

`xconfmanager --setfromfile myPropertiesFile.properties -t ptcPropertiesFile.properties`

This will take your properties file and use the site.xconf to append/change those properties in PTC's properties files.  All the ptc documentation points to using `xconfmanager -s 'key=value' -t ptcPropertiesFile.properties`, but that's easy to lose track of.

[gprajeesh77]

Hi @bcedar bcedar,

We are using now Gradle / ant script + SVN

I have one clarification needed

You mentioned you are doing all your customization outside WT_HOME

So when you build final delivery, you might be customizing the java files. So if the Java files are outside, how you using the tools.xml to compile the java files?

Do you changes the preferences, acl using UI or you use the loaders to load it as part of pipeline

Thanks

Prajeesh Kumar

[bcedar]

We use wtSafeArea and wtCustom as stage areas....

We maintain a folder called server_files in our source control.  Under that folder we have C and E folders which represent the drive the file needs to go into.  From there it's an absolute path to where the file needs to go.  wtSafeArea and wtCustom are simply used in that.  Attached you'll find a 'tree' output run from my server_files folder.  You'll se the C and E top level directories and paths from there.

My goal for this repo is not only to manage the windchill app, but to capture all the configs and processes involved in standing up the windchill app and server from initial installation of the OS.  (not really realistic right now because PSI hides so much work from us, so from a gold image may be what we end up doing)

[gprajeesh77]

Finally, I was able to make all the development work outside windchill home and created a separate workspace for development and able to integrate with ant +ivy+Git+Jenkin Combination for CI. I was forced to write some code specifically for loading the administrative data + Test data 

Once the containeration is in place, It will be even smooth to do CD/CI