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.
Re: Perl Management
by etcshadow (Priest) on Dec 14, 2003 at 03:23 UTC
|
| [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.
| [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.
| [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] |
|
|