Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

[chirag_kpit]

How can we enable versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager?

Better  if this can be done using some solution related to configuration Management.

[kjain-2]

Hi Chirag,

Do you mean to store the trigger scripts & report recipe files in any version control tool?

If this understanding of mine is correct, then you may use SVN / GIT / IBM Clearcase / Integrity SCCM or any equivalent tool depending on your company's standard policy.

Grube,

Kapil

[chirag_kpit]

Hi Kapil,

I am looking for a solution using Integrity SCCM, but how can I implement it.

Regards,

Chirag Agarwal

[kjain-2]

Hi Chirag,

May i know what is the exact scenario for which you are looking into this requirement ?

Grube,

Kapil

[chirag_kpit]

Hi Kapil,

I don't want to give server access to any user and also i don't want users to make changes to any directory using URL.

I want users to checkout the trigger script and check in, for changes to reflect in the server directory , this is how i am looking to implement it.

Regards,

Chirag Agarwal 

[MichaelChatel]

At least in the case of trigger scripts, are these users making changes to admin objects, not supposed to have admin access to the server?  It's not like any old user will have access to edit trigger scripts?

This seems like it could get messy, and that you would have to do a bunch of copying of "checked-in" scripts, to the proper locations, to use on the Integrity server.  I don't know anyone doing this.

[chirag_kpit]

Hi Michel,

May be it seems messy but it's not. Some customers have such functionality and some customers are willing to have such feature. I am actually using this but not knowing how this is implemented.

This will help users and implementors in various ways-

Let's say you are not willing to give server access to all the users then this will be helpful by giving project permission to specific set of users, another if you want to revert the changes in script you can directly revert if have such functionality and also you can compare the difference in two versions and many more.

This feature very powerful.

Regards,

Chirag Agarwal

[mks2019]

Will it be possible with File Vaulting?

just a guess.

[JoeBartlett]

Anecdotally, I have seen one customer with this kind of configuration. If I remember correctly, they had created a group for Admins and created a new top level project for the server trigger files. /ServerConfig/project.pj or something similar, which only the Admins group had access to.

They had used an Integrity Client installed on the Integrity Server machine and they created a sandbox in the same location as the <IntegrityServer>/data/  folder such that all of the files and folders within that location were considered Members of that ServerConfig project.

Since they had locked-down the permissions to only the Admins group, normal users could not access that project or make changes to the files - only the Admins could. They would only make changes to the files by using the client on the server, and this would be tracked by Integrity as new versions of the files.

The risk to handling the server config files in this manner is that if an admin were to accidentally drop the sandbox on the server and choose to "delete everything" when prompted, the server would not be able to start next time the service is cycled. With the server not being able to start, it would be impossible to retrieve any earlier versions of the files from Integrity since it would be offline. An apt analogy for this would be locking your car keys inside your car. If you plan to go with this configuration, know that it is not recommended by PTC and you are very strongly encouraged to take filesystem-level backups to mitigate that risk.

[VolkerEckardt]

In my current project we handle this the following way:

1. we have an additional project Integrity Server

       Key Users, PMs, Developers will usually have access to

2. in this we handle everything like 

       a) project documentation

       b) custom user manuals

       c) configuration tests and test results

       d) source code including Java, Trigger, Reports, Templates, ...  just everything

       e) Change Requests and Defects

       f) Business User Stories to link code, CRs and Defects to.

3. When a developer is ready with his own development, we check the result in into the project server, and perform a formal validation.

When ok, we deploy the solution selectively into the TEST > QA > PROD chain.

4. The configuration manager is responsible to take the changes up and promote them as requested.

We are also using some helper scripts to make sure that everything is stageable, e.g. also Gateway files. 

[chirag_kpit]

Hi Volker,

Thanks for your response.

Your understanding is exactly same that i was looking for.

So, I would like to know how this solution has been implemented because configuration manager checks-in the file into  the database not in any physical location/directory.

Regards,

Chirag Agarwal

[chirag_kpit]

Hi Joe,

Thanks for your response.

In Case, we installed Integrity Client on server and  created a sandbox  with Integrity Server directory Locations then how, the checked in files are getting reflected into the server directory without re-synchronizing the sandbox ?

As per my knowledge, files will not be physically available without re-synchronizing the sandbox.

If you have created any trigger or script for this then how you manage to create the event?

Regards,

Chirag Agarwal