Recently, a customer came to me because they wanted to record when changes were promoted from their development environment to their test environment, and later from their test environment to their production environment. They wanted a way to simply tell when changes were moved to test, and then promoted to production that they could easily refer back to.
To accomplish this I turned to Audit Logging in PTC Integrity Lifecycle Manager. The purpose of Audit Logging on a PTC Integrity Lifecycle Manager server is to allow you to capture the results of operations that are performed on the server. In much the same manner that PTC Integrity Lifecycle Manager keeps a record of any and all changes done within the system, audit logging on the PTC Integrity Lifecycle Manager server can provide you with a record of all activity on the system whether done by an administrator, user, integration or trigger. PTC Integrity Lifecycle Manager allows you to configure your audit logging with a fine level of granular control. We will be taking advantage of this fine level of control to effectively keep a running tally of what has been promoted from one environment to another.
In terms of using audit logging functionality to track promotions in the PTC Integrity Lifecycle Manager environment, there is another important aspect to keep in mind. If you have your environment configured as follows:
You’ll note that the Staging and Production servers are locked. That means other than changes promoted from the previous environment, administrators cannot make changes independently in either Staging or Production. You’ll see how we can take advantage of this when we implement our Audit Logging as shown below:
1) The first step is to turn on your audit logging on the Staging and Production server. We’ll keep an audit log for every admin activity that takes place on both the Test server and the Production server. Since both servers are locked, the only admin activities that will be recorded are those resulting from promotions. To set up the audit rules you’ll need to update the is.properties files on both servers to all the following:
Note: Changes made to the is.properties file will not come into effect until the next time the PTC Integrity Lifecycle Manager Service is restarted.
2) Restart your PTC Integrity Lifecycle Manager Server by using the mksis restart command.
Note: Running this command on a Production server will cause a service interruption to your user community. Be sure to schedule a maintenance window or server outage with your customer base before performing this activity.
That’s pretty much how it is set up. It’s fairly easy. The next section of this article demonstrates how the audit log that we set up, works. In this example, I promote a relatively simple viewSet change:
Provide a description of what it is you’re promoting. A best practice in this area would be to add a Change Request ID, Defect ID or Work Item ID that describes the work you are doing.
Once the change has been promoted…
You can open the Audit log on the destination server by selecting “View Audit Log…” from the Administration client as shown below:
You will be presented with a filter to screen your results. In this case I’ll simply leave everything blank to retrieve the entire contents of the Audit Log.
This will retrieve the following audit log. This audit log provides the record of what has been promoted from the previous environment to the current environment.
If you are looking to provide a record of everything that has been promoted through your staged environment, from development to production, then using the Audit log as I described here can provide everything you need to keep track of changes to your PTC Integrity Lifecycle Manager environment. Having a record of such changes to your environment is often a necessary requirement in regulated industries, such as those found in the Aerospace, Automotive, and Medical Device sectors.
