in reply to Finally! Saying goodbye to perl 5.005

You will have to recompile every single module you're using as 5.005 and 5.8 are not binary compatible. In addition, some Perl modules will modify themselves depending on the installing Perl version.

These are the steps I see, in order:

  1. Get your boss's buyin that this will be a 6-month process.
  2. Get your code into source control. Subversion is probably best, here. This is non-negotiable failure point.
  3. Get some sort of one-step deployment/build process. This may involve adding configuration files, writing scripts, and the like. This is non-negotiable failure point.
  4. Get a machine that you and only you control. Since you're running Linux, converting your desktop should be plenty powerful. The goal is isolation, not power. (I did this at my last job and my desktop was the production webserver/dbserver for a few months.) Ideally, not even the sysadmin has root on your box. This is a non-negotiable failure point.
  5. Build your ideal system on your isolated machine. Once you have it built (Perl / DBD modules / apache / mod_perl / mod_ssl / database / etc), take a snapshot. Ghost is good for this, but any backup/restore will do. Remember - you have to deploy this configuration a few times. You will want to be able to do this without having to remember to install foo before bar but after floober. This is non-negotiable failure point.
  6. Write down a series of acceptance tests. Focus on the critical systems. For example, if you were developing Quicken, you'd start your tests with the lineitem entry stuff and worry about the pretty graphs later.

Note - none of the above have anything to do with Perl, specifically. They're good practices for any kind of major infrastructure upgrade.

Oh - those failure points? If you don't do them, you fail. Period.

Once you have done all that (about 3-6 weeks work), then you can start the actual work of migrating your codebase from 5.005 to 5.8.x by doing a build from source control to your isolated box, then running your acceptance tests against it.

Have fun - this is a wonderful project that will give you amazing kudos when you get it done.

  • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
  • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
  • Comment on Re: Finally! Saying goodbye to perl 5.005

Replies are listed 'Best First'.
Re^2: Finally! Saying goodbye to perl 5.005
by beauregard (Monk) on May 06, 2005 at 01:46 UTC
    Build your ideal system on your isolated machine. Once you have it built (Perl / DBD modules / apache / mod_perl / mod_ssl / database / etc), take a snapshot. Ghost is good for this, but any backup/restore will do.

    I strongly agree with most of your points, but taking snapshots is a very effective way to be in the same boat a few years down the road when you have to do the migration again. Especially if your starting point involves cloning a developer desktop machine. You might as well be doing brain surgery in a crack house!

    I've been down the system cloning road and here's what I do to avoid it:

    The thing you want to do, while you're building your ideal system, is to document the living daylights out of the setup process and automate as many steps as possible. For example, rather than documenting all 50 CPAN modules you need to install, create a new module with all the dependencies already mapped out (Makefile.PL's PM_PREREQ, for example). Installing it should suck in everything else you need. Put your web server configurations into your SCM.

    The final goal is that a literate monkey can take bare metal and some CD-ROMs and just build your ideal system from scratch in a few hours. Repeatedly. And if it's not the identical O/S with the identical version of perl, apache, etc, having a repeatable process should work around all the little details like binary compatibility and whatnot. As long as it passes the acceptance tests. That's a non-negotiable failure point.

    c.

[reply]
      The idea is to reprovision a developer desktop into what a production server should look like. Then, take a snapshot. I agree with you completely that you should also be able to build any server in your network using a literate monkey, bare metal, a T1, and some CD-ROMs. But, that doesn't mean you can't have both.
      • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
      • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
[reply]
Re^2: Finally! Saying goodbye to perl 5.005
by the_slycer (Chaplain) on May 05, 2005 at 17:57 UTC
    Thanks for the comments.

    We are using cvs, so that will be the source control tool, and we'll be creating a new branch for any development that needs to occur for the change to be succesful.

    The acceptance tests are a bitch, but I'll give it the best go that I can, just some background, I came into this company a year ago, we're slowly moving everything to java from perl, but it's a slow enough process that we can no longer put off upgrading perl.

    The code is quite simply some of the most horrible code that I've seen, the guys that started this system off did not know perl very well at all, worse, they didn't know how to program (we've got 8000+ line INLINE scripts - no subs)

    In addition, nothings documented, some of the code is stuff that just runs, hasn't been looked at forever, and nobody really knows what it's supposed to do. It's a major headache just trying to maintain the stuff, it would be good to get some tests written during this migration to help with the maintenance afterwards...

    It should be a good time, and I do have the buy in for the timeframes, machine, etc..
[reply]
      slowly moving everything to java from perl

      If you really are moving everything from perl to java, I'm not surprised that things are going slowly.

      nothings documented, some of the code is stuff that just runs, hasn't been looked at forever, and nobody really knows what it's supposed to do.

      Read "Perl Medic".

[reply]
      I would argue then that building the acceptance tests is a non-negotiable failure point. You know what the heck is going on or you fail. *shrugs*
      • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
      • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
[reply]
Re^2: Finally! Saying goodbye to perl 5.005
by splinky (Hermit) on May 05, 2005 at 18:27 UTC
    Every so often I desperately wish I could vote a node up, like, 5 or 10 times instead of just once.
[reply]

In Section Seekers of Perl Wisdom