cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

Level 7

Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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.

11 REPLIES 11

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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

 

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

Hi Kapil,

 

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

 

Regards,

Chirag Agarwal

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

Hi Chirag,

 

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

 

Grube,

Kapil

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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 

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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.

 

 

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

Will it be possible with File Vaulting?

just a guess.

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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.

Highlighted

Re: Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

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.