I asked this question in Chatterbox because I thought it not especially important. Then I thought it might be important to me. And anyway no one gave me an answer.

There is a slight possibility that Perl will start being used in my shop. And a slight possibility I might be asked to make some recommendations on how to manage our use of Perl. Questions: Where is Perl in your shop(central server or individual machines)? Are your module downloads regulated or can everyone choose their own? Do you have a CVS? Anything else it would be good to consider?

Thank you,

xenchu

Update:First, I want to thank everyone who replied. Your input is both useful and appreciated.

Let me expand a bit on what I wrote originally. I work in the Business Department of a State University. Mostly we use Cobol and Focus on an IBM mainframe. Recently the school bought some web software packages to allow such activities as grading by faculty, grade checking by students, overdue bill notification and a great deal more via the web. The university also belongs to a consortium of schools in this area that use this software. The consortium voted to use Perl for web programming. That doesn't mean we will but it is a solid nudge in that direction.

We have source management software named Endevor but since it is on MVS on the IBM mainframe we probably could not use it for Perl (is there an IBM MVS Perl?). In fact, one of our sys admins (at least) uses Perl, but that is a personal copy of Perl on a Unix machine(the school has several that we don't program on). Our change control at the shop is good and always has been. If management fears that Perl cannot be managed, it will not be used by the department. That is just about a certainty. That is why I asked about change control. It is important and strictly managed in my shop. In fact, it is mandated by the state.

I have two copies of Perl on my machine at work. Activestate Perl for my Windows OS and the copy that came with RH Linux 9. My manager is aware of this and is ok with it as long as I don't use Linux during working hours.I also have RH Linux 9 on my machine at home.

BTW, after we got this new web software, we started acquiring webservers, Oracle, SQL, etc. SQL is not, as yet, under change control as far as I know. Even though most of this software is not the responsibility of Business, I am hopeful that this will nudge us toward Perl.

Again I want to thank everyone who answered. My optimistic guess is that the soonest we could get Perl would be one year. But I want Perl at work, so I am trying to plan ahead.

Thanks again.

PS. I'm a real Monk now!

The Needs of the World and my Talents run parallel to infinity.

Replies are listed 'Best First'.
Re: Perl Management
by etcshadow (Priest) on Dec 14, 2003 at 03:23 UTC
    This is how we manage it in my shop:
    • Our server code (perl) and any modules which we use but modify heavily go into a source code repository. Perforce, actually... not cvs. It costs money but IMHO it is worth it. It's really not that expensive and it's excellent software, multi-platform, very scriptable.
    • Standard modules which we use get loaded into a general system image which we sync out to all of our servers, along with standard binaries and non-perl libraries... even the O/S (currently SLES7).
    • There is a little bit of a review process before we add libraries to that image. It's worth it. Any old idiot can slap something up on CPAN. Saying "it's safe because it's on CPAN" is kind of like saying "it must be true, I saw it on the web."
    As for you, what is best really depends a lot on what you intend to do with this perl code. Where I work: we write a large business application built on apache/mod_perl and oracle. It's all centrally located and managed and load balanced. So we have to worry about a whole ton of machines, all of which fall into three categories:
    • application servers
    • oracle servers
    • other servers (administrative machines, web proxies, etc)
    So we need a way to make sure that all of our systems admin scripts make it out to all machines, and all of the code makes it out to all of the app servers. Anyway, that all means that we need a pretty heavily controlled environment so that it can be synchronized easily. Your needs may be different.

    ------------
    :Wq
    Not an editor command: Wq
[reply]
Re: Perl Management
by pg (Canon) on Dec 14, 2003 at 03:01 UTC

    So if this becomes true, it is a break through for Perl in your shop. Try to do everything as perfectly as possible, so more and more chance might come up for Perl in your shop.

    You already did the first thing absolutely right: focus on change control.

    cvs (or other tools like clear case) for sure. This is always true for all projects, regardless what the development language you use. Not just your Perl source code, but also any document, test data, test script.

    Remember that cvs is nothing, if there is no well defined rules of using cvs. Whatever how good the tool is, you can always use it in the wrong way. Especailly with tool like cvs, it is about discipline. If you want I can share with your the change control process in my shop. We have a document for change control, and you obviously need one.

    You should allow people to download modules from CPAN and play with them. At the same time, there should be a control point, to determine whether a module can be used in production system.

    Try to do an excellent job on code review, and testing.

    Good luck!

[reply]
Re: Perl Management
by Zaxo (Archbishop) on Dec 14, 2003 at 03:25 UTC

    Are you to code for internal use, for a variety of customers, or for wide distribution? The answer should determine how many versions of perl you'll want to have around. They can be installed with a version prefix allowing the binaries to mix in the same directory.

    Work to forestall institutional resistance to installing additional modules. Plenty of arguments for that can be found here at perlmonks. You can't easily prevent people from installing modules in their home tree, and it would be useful to help them do that. It's not hard to write a perl program to create a ~user/.cpan/MyConfig.pm file set up for ~user/lib/perl5 and to provide $PERL5LIB to the login shell environment.

    The advice about cvs is crucial. Make sure it is a somewhat dedicated development machine and have your many perl versions on it. You don't want production concerns and development needs to interfere with each other.

    After Compline,
    Zaxo

[reply]
Re: Perl Management
by derby (Abbot) on Dec 14, 2003 at 12:56 UTC
    In our shop (which creates and maintains a medium sized web site), we put perl in a central location (/usr/local/bin/perl). All the CPAN modules we use also stay in the default locations. All the modules we build go in a special directory that we add to @INC when we build perl. The modules we build are CVS'ed - the stuff from CPAN is not.

    Also, we have the classic dev/test/production environment. When we upgrade perl (and CPAN modules) we first install in dev, sit and stew it, then promote to test, let simmer, and then if all is well, promote them to production. So although we don't CVS perl or CPAN modules we do at least have a fair amount of confidence in upgrades before they go into our final product.

    -derby

[reply]

      Similar to derby, I work with a dev/test/prod environment. As a developer, I can install modules under my own home directory (and since it's NFS mounted to all the dev machines see it everywhere). Perl is in a common location (/usr/local/bin/perl) and the modules under @INC are controlled by our Ops dept.

      Test is more strictly controlled (files must be changed in dev and migrated to test) and prod has very limited access.

      As a number of other posters have pointed out, you're best bet is to establish appropriate controls. If you can establish a dev environment where people can play with relative freedom you will have much less resistance to locking down your production environment.

      Oren

[reply]
Re: Perl Management
by exussum0 (Vicar) on Dec 14, 2003 at 15:45 UTC
    You should regulate it like ANY OTHER software shoppe should.

    number a. Keep anything that could change during the lifetime in the company in cvs. And anything that can be derived from it, out. Source code, html, gif's for the website, server configurations, yes. Compiled binaries, no, unless you have no source for them.

    b. learn change control. I mean this two fold. 1. learn cvs and usage techniques, such as branching and tagging and when to use them. 2. Dependency management is a pain in the ass. Internals to modules chnage, and develoeprs aren't always the most vocal bunch to say, "I'm using ThisModule.pm version 1., 2 breaks my code." Sometimes they simply aren't aware.

    I think you opened the wrong can of worms :) You see, you aren't asking about using perl per-se. You are asking about developing and maintaining a system. You may want to pick up a book on systems analysis and design, as well as software engineering. You don't have to use ALL the concepts in them. After all, you have limited cash and resources, and experience. Each company works in unique ways, but more importantly, you should look at examples and test ideas that other people use. CVS (cvs/perforce/subversion) and change control, qa... overly excellent ideas that no one should do w/o. How your software starts and finishes from an idea to comletion and maintenance, that is accomplished via growth.


    Play that funky music white boy..
[reply]
Re: Perl Management
by Anonymous Monk on Dec 14, 2003 at 04:57 UTC
    I would guess the first thing you have to analyze is how are your current languages/libraries managed? Managing Perl in a shop is not inherently different from other languages, and you probably do not want to make the use of Perl completely different from your existing structure (unless the existing structure is broken or ill conceived).
[reply]
Re: Perl Management
by Anonymous Monk on Dec 14, 2003 at 04:43 UTC
    It is rather simple to build your own copy of Perl. This will be important especially if you are running Solaris or HP-UX which ship with particularly ancient versions. Taking the few minutes to build a copy will also save you from debates over whether adding/modifying modules will harm any existing system utilities: they are immune from you since you have your own install.
[reply]
      Actually, Solaris has been shipping with the most recent version of Perl available at the time the Solaris release was made for quite some time. And for the sake of backwards compatibility, they ship the previous used version as well. (That is, Solaris 10 will have the version of perl that came with Solaris 9, plus the newest stable version of Perl the moment Solaris 10 is made).

      Abigail

[reply]
Re: Perl Management
by TVSET (Chaplain) on Dec 14, 2003 at 23:04 UTC
    Two things reall I'd like to add to everything that has been said before:

    1. You might as well check other alternatives to CVS for code management, such as arch and Subversion.

    2. Encourage developer discussions about modules they found on CPAN and/or elsewhere. This will increase the productivity of the group and maintainability (spelling?) of the code.

    Leonid Mamtchenkov aka TVSET

[reply]
Re: Perl Management
by gri6507 (Deacon) on Dec 15, 2003 at 20:21 UTC
    I know that at least in our shop, we use RCS for version control. It does an excellent job for both code (Perl and otherwise) and binary files (ie word documents that go along as documentation).
[reply]

Back to Meditations