Since its introduction into the Agile PLM product, the buzz around Groovy has only gotten stronger. I first saw Groovy during the Agile 9.3 prerelease partner product testing program in which we were encouraged to test the functionality as exhaustively as we could. Since then, we continue to hear our clients mention Groovy on a regular basis.
Before climbing on the bandwagon and jumping up and down like a high school cheerleader, let’s think about the PLM with respect to change and configuration management. When rolling out a change order, there is a predefined workflow that the change is routed through with a set approval process. So does it make sense to allow an admin to go in and change scripts that can have a serious impact on your system without a reproducible build and versioning? Could you imagine doing that on a mass produced part?
As of Agile 9.3.1, the revision history for Groovy scripting is lacking. As you can see from the picture below, the exact changes made to the scripting are not available. “Modified Script” doesn’t exactly tell us much, does it?
Having been in software development for quite some time now, I am accustom to version control, build systems, and writing quality assurance review (QAR) documents. With version control, we can put tags on files that are specific to a release. Since tags can get moved, QAR documentation can be even more specific as to the revision number on each file that is included in the build. If your company uses a continuous build tool then this may create a build manifest automatically for you allowing you to go back at any time in the future and be able to reproduce the exact same deliverable
Want to take it a step further? If you use a system such as SVN or CVS there are variables at your disposal to allow you to actually have each piece of source code “auto document” themselves when new versions are checked in. For example, we could create a method that implements something like the following:
public void showRepositoryInfo() {
StringBuilder display = new StringBuilder();
display.append("$Author$").append("n");
display.append("$Revision$").append("n");
display.append("$Id$").append("n");
display.append("$Date$").append("n");
disply.append("$HeadURL$").append("n");
System.out.println(display);
}
When I check it in, the variables automatically gets populated to look like:
public void showRepositoryInfo() {
StringBuilder display = new StringBuilder();
display.append("$Author: rmccabe $").append("n");
display.append("$Revision: 5 $").append("n");
display.append("$Id: AlphaLoader.java 5 2011-05-10 19:31:25Z rmccabe $").append("n");
display.append("$Date: 2011-05-10 14:31:25 -0500 (Tue, 10 May 2011) $").append("n");
display.append("$HeadURL: https://svn/legacy/toolbox/src/AlphaLoader.java $").append("n");
System.out.println(display);
}
To summarize my thoughts on this it really comes down to two things:
- Groovy itself is nothing more than a scripting language which is more than capable of doing the job. Because it is text entered with Agile itself however, migrating changes across environments will require manual entry which can introduce errors.
- Even if errors were not introduced through the script modification there is insufficient means to know what was changed on the event handler object. I specifically chose to show the detail on the modify history row because I believe that is the tab where the new and/or old version should be displayed so administrators can look back and know what changes have taken place in the system.
I find it incredibly interesting that a system such as Agile offers the flexibility of scripting but not the control necessary to rollback or at least view the modification history. Ideally having a framework that would control customizations and prevent accidental changes would be very useful. What are your thoughts?[clear-line]