How we can use PERL for Build and release engineering automations?what sort of tools can be created with PERL?

Basically, Perl is a string-matching and manipulating language. It's wonderful for taking standardized inputs, looking for specific sequences of characters (or bits; Perl can be used to manipulate binary sequences as well as ASCII), and doing "something" to them -- converting them to another form, or inserting tags at specified points, or capturing sequences of text and inserting them into templates.





Because Perl is so string-friendly (for input and output), it's a great choice for CGIs in a Web page.





You can also use Perl to run system functions (at least I've done this on Unix installations; I believe it's possible to run DOS-type command line functions on Windows Perl, but I've never done that). This includes writing files, renaming them, and deleting them.





In a build and release automation, for example, you could:





1 - Create a Web page that used Perl to let the user upload a module to the compile directory, checking for file-name structure on the "way in"





2 - Trigger an automatic email to the build manager to alert that a new file had been checked in





3 - Execute a script (either automatically or through a Web interface) to build object code out of the checked-in modules





4 - Automatically, at the termination of the build, send email to the build manager (or others) that a new version was available





5 - Automatically, at build termination, delete any intermediate or temporary files constructed by the compiler





My own experience with Perl is in the area of converting large (750+) numbers of text files from an input format to individual Web pages, in a batch form. Most recently I was tasked with extracting data from a proprietary Web-based customer care system (in a single file containing 250-odd records) and turning the data into in-product Help, in Microsoft CHM form.





Perl made it a simple process of cleaning up the extracted data, splitting the extracted data into a series of string variables, then printing each string one by one inside a template for the Web page we were using as input for the Help Compiler. Took less than three minutes to convert 250+ files from the Web-based report to a compiled CHM file ready to hook up to the product's Help menu. It would have taken, oh, maybe two or three DAYS to convert the files by hand, copying and pasting the content from each line of the report into the Web template. This freed the content expert (which also happened to be me :-) to concentrate on getting the content right, rather than on simply trying to get the copy-and-paste part right, at three days a hit.





Some recommendations to make development and debugging easier:





1. Break your task into small modules, then write a separate Perl script for each module. This makes it easy to see where your process is causing problems while you're still developing, without having to search through the entire set of scripts.





2. Use some kind of "uber-script" (I wrote mine in the Bourne shell, on Unix, but I suspect an MS BAT file would work -- check the docs for the version of Perl you use) to call all of these small Perl modules in sequence.





3. Make sure your "uber-script" lets you know which Perl module is executing, so that if the process terminates unexpectedly you know where to start looking for problems.





4. In early development, have each Perl script "tell" you what it's doing -- reading in a variable, changing all the Xs to Ys, writing an output file -- just as it's about to do it. Then if it terminates unexpectedly you know where to start looking for problems.





5. Once it's running smoothly, don't delete the lines that "tell" you what each script is doing -- comment them out. Somebody, someday, is going to enter a file or a command or a block of source code that doesn't do what it's supposed to do, and you'll want to turn those "tell me" lines back on to see where it's failing.





6. Comment, comment, comment! My own Perl mentor told me to write comments "as though you were writing for a stupider version of yourself -- because in six months when something goes wrong and you dive into the code to try to fix it, you'll BE that stupider version of yourself trying to remember what you had in mind when you wrote the silly thing."





That should be enough to get you started. Other than that it's standard system analysis -- look at your process, look at all the little pieces, figure out their inputs and outputs, and start coding.





Best of luck!