Skip to main content
T
23-Emerald IV
TomU23-Emerald IV
23-Emerald IV
August 26, 2020
Question

How to track and manage changes to the Windchill installation

  • August 26, 2020
  • 6 replies
  • 14833 views

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.

    6 replies

    A
    AndyHermanson14-Alexandrite
    14-Alexandrite
    August 26, 2020

    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. 

      B
      bcedar1-Visitor
      1-Visitor
      August 28, 2020

      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!

        B
        bcedar1-Visitor
        1-Visitor
        August 28, 2020

        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.

        M
        22-Sapphire I
        MikeLockwood22-Sapphire I
        22-Sapphire I
        August 26, 2020

        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.

          M
          22-Sapphire I
          MikeLockwood22-Sapphire I
          22-Sapphire I
          August 26, 2020

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

            J
            jvonzastrow115-Moonstone
            15-Moonstone
            August 27, 2020

            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.

            F
            fivig5-Regular Member
            5-Regular Member
            August 27, 2020

            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:

            T
            23-Emerald IV
            TomU23-Emerald IVAuthor
            23-Emerald IV
            August 27, 2020

            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???

              M
              22-Sapphire I
              MikeLockwood22-Sapphire I
              22-Sapphire I
              August 27, 2020

              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.

                T
                23-Emerald IV
                TomU23-Emerald IVAuthor
                23-Emerald IV
                August 27, 2020
                @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.

                Terms & ConditionsCookie settingsAccessibility statement