Intro to Configuration Management

[brague]

Hello,

I have been tasked with setting up configuraiton management in Integrity 10.2, mainly for use with version control of trigger scripts and properties files. Despite about a week of effort, I am still very lost in how to set it up on a server or how it works. I have found/been directed to all the detailed information on CLI commands, Best Practices, etc. but I still lack a clear picture of how configuration management works from a high level perspective. I am curious if there are any documents/videos/discussions that I could be directed to which would give me a general framework of how configuration management works in general and how it fits into the big picture of Integrity itself. Any tutorial or "How-to" type material would be a life saver at this point in time.

Also, if configuration management isn't the correct tool for version control within Integrity, please let me know so I can take this information to my team.

Much Appreciated,

Bryan R.

[matt_giltaji]

Hi Bryan,

I don't know of any videos, but at a high level this is how we use version control on our trigger scripts.

1) Create a new "configuration project"

This is a mini-repository which keeps your scripts & properties files separate from other source code artifacts. You can set up permissions on this configuration project so that only you and the rest of your admin team have access to the scripts and properties.

2) (optional) Enable "change packages" on some Integrity item type used to track changes to your system

This falls into the "best practice" realm. We have found it useful to have the changes to trigger scripts linked to the ticket which requested those changes. In some cases, we look through the revision history and wonder "why did we code it this way?", so the ticket adds insight to that. In other cases, we may get a new ticket which sounds similar to an earlier change, so we look up the earlier ticket and see what trigger script changes were made at that time. It may not be useful for your environment.

3) Create a new mainline/regular "sandbox" of the new configuration project.

This will be an empty folder because the config project starts off empty. We will use this sandbox for the initial check in of the existing trigger scripts and properties files.

4) Add the existing trigger scripts & properties files to the sandbox location

You may want to take some time to plan out the folder structure for the scripts as this can be tedious to change later on. We have 2 top level folders in our environment, "triggers" and "utilities".

5) In the client, open the sandbox from (3) and go to sandbox->views->view non members

(This is the time to create a Change Package if you are using Change Packages (linked to item types or not)

This will open up a big window with a list of all the files and folders that you added in (4).

Highlight the files you want, then click the blue plus icon to add them

Follow the prompts to add the files

6) if you are using change packages, submit your change packages and your triggers/properties files are now in integrity for version control.

The detailed process for how you use the version controlled trigger scripts will vary based on your set up, but the high level process might be something like the below:

1) receive the request to make a change

2) get necessary approvals/planning done for the change

3) if you are using change packages, open a change package

4) perform a "check out" operation on the trigger scripts which will be updated

5) make the necessary changes to the files in your sandbox

6) if you have an admin staging server/test server, deploy the updated trigger scripts to the staging/test server

7) test your changes

😎 adjust scripts as needed

9) perform a "check in" operation on the trigger scripts (Submit the change package if you use change packages)

10) deploy the final version of the scripts to the production server

11) notify users/requester that the changes are made.

Hope that helps,

Matt

[brague]

Matt,

This information is excellent. It all finally clicked and I now understand the basic use and functionality. The detailed steps on setting up the project and sandbox were exactly what I was looking for. The example steps on how check-in in and check-out fits into a deployment process will be very helpful as we determine out best practices. I should be able to figure out the specifics from here, thanks so much!!

Sincerly,

Bryan R.

[hsprang]

Hello Bryan,

I also have no top level overview on how the SCM works best with PTC, but I recommend you getting in contact with PTC support / your key accounters.

For our initial setup of the SCM system in PTC (MKS) some 13 years ago we had ordered some consulting. They analysed our software structure and recommended how we best could set up the SCM system. This was really beneficial and we learned a lot. Also the structure and triggers were (and are still) quite quick.

Meanwhile the structure had changed and we adapted everything on our own. But the knowledge and hints we got at the beginning were quite useful.

Regards

Heike

PS: no, I am not working for PTC

[brague]

Heike,

Thanks for the recommendation! I will have our team consider consulting after I prove to the team that we can use Configuraiton Management to effectively version control our scripts.

Thanks again,

Bryan R.

[KaelLizak]

Hi Heike!

Thanks for replying to Bryan's question!

Also, you can tell who the PTC employees are here, because they do not get a star under their avatar.

Regards,

Kael

[KaelLizak]

Hello Bryan,

Thank you for participating in the Integrity Community!

In general, for learning materials, you should contact -. I understand that there is development of Source Integrity learning materials in process right now.

If - does not have the information you are looking for, then as Heike recommended, you should contact your account team, since they should have some idea of the kind of configuration that would be most appropriate to your needs.

Regards,

Kael