Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: Professional development with Perl - how it's done?

by perrin (Chancellor)
on May 29, 2006 at 22:42 UTC ( #552382=note: print w/replies, xml ) Need Help??


in reply to Professional development with Perl - how it's done?

Finding the right deployment strategy takes some practice. I'll tell you some basics of how we do it at http://plusthree.com/, for a fairly large Perl application.

First, we keep the code in Subversion. In addition to some obvious benefits of avoiding overwriting each other's work and keeping long-term undo, it's the only way to deal with needing to keep a released version working with occasional patches while you build a new version. This is done with branches.

Next, you need to make a release somehow. We have a script that build release packages. They aren't much more than a .tar.gz file, but some things that are only relevant for development are left out, and care is taken to avoid over-writing config files.

We move that to our server, where we unpack it and run an automated build script that builds all the included CPAN modules. Then we run upgrade scripts which make any required database changes between releases.

We include the CPAN modules in their normal compressed state and automate the whole unpack, Makefile.PL/Build.PL, install business. We install them into a local directory, not the site_lib on the machine, and point our apps at that directory. This means that we always know exactly which version of a module we're using and never get burned by a change in a module's API on an upgrade.

There have been cases where we needed to modify a CPAN module. In that situation, we move it to the source tree, at least until a later version that no longer needs our changes is released. (And yes, we share our changes with the authors in these cases.)

Since we're dealing with dedicated hardware, not a cheap shared host, we control the environment as much as possible. We build our own perl, so we can count on knowing the version and the compile options and not be surprised by a special Red Hat patch or a missing Scalar::Util feature. We also install a specific version of the database, so we know what to expect from it too.

If you're building something to run on shared hosts, or your project is small, then this may be overkill for you. It's been really helpful for us though. You can see most of this in action in the Krang CMS project, which shares many of the same build and deploy approaches.

  • Comment on Re: Professional development with Perl - how it's done?

Replies are listed 'Best First'.
Re^2: Professional development with Perl - how it's done?
by techcode (Hermit) on May 30, 2006 at 10:49 UTC

    Yes cheap shared hosting is what makes problems to me most of the time. As I'm still a small fish and don't want to cash ~ $100+/month for dedicated server I took one of those VPS for my needs. I also sugest that most of the customers should take at least VPS (they start at $20/month) if for nothing else than mod_perl/FastCGI posibility.

    The thing is that applications being developed are also to be sold to 3rd parties of which most will have shared hosting. And under those conditions only pure Perl modules will work ...

    Anyway - in case you want to start using a new module, you first import it in the repository, then do a new export/chekout (script that builds releases handles it). And then you can use it, right?

    Are there any articles/books/whatever on this subject? But something that can be applied to Perl?


    Have you tried freelancing? Check out Scriptlance - I work there.
      I'd expect even a shared host to have a compiler installed.

      When adding a new module to the repository, we just check the downloaded CPAN package into a directory and then run the build script. It finds all CPAN packages in that directory and builds them.

      Most of the articles about software deployment and configuration management tend to be about Java, since many LAMP developers do this kind of thing in sloppy ways without much thought. It's only when you get into larger apps that you realize the necessity of thinking through infrastructure like this. However, you may find some useful things in the archives on the http://onlamp.com/ site.

        Ah I don't know if it has gcc but one of shared hostings that I use doesn't have pod2man - so compilation fails ...

        Have you tried freelancing? Check out Scriptlance - I work there.
Re^2: Professional development with Perl - how it's done?
by Qiang (Friar) on Apr 06, 2007 at 13:18 UTC
    I have been looking for ideas about how to automate Perl app deployment and module managment.

    currently, we have all the commonly used modules (such as CGI::Application and other in-house modules) in a central perl lib directory and all apps use it from there. problem may arise if a module gets upgraded with API changes and such. but i think testing may help us stay away from trouble.

    to your reply, I am wondering why not unpack all needed modules locally once for your app in development and save to cvs. when deploy to the production, just cvs out. be done with it? (the only reason i can think of not doing it is unless you need to deploy to different OS). rebuilding same modules on dev,QA,production sound tedious.

    or, you can keep all unpacked modules in a central location, copy to new app when needed without rebuilding it for every release.

    thoughts?

      Compiling once the way you describe will only work if you are sure you never need to support another OS, different hardware, or a different version of Perl. These things will also change over time. You will want to upgrade your OS and suddenly find you have to recompile all of those modules by hand. Building an automated installer makes this easy, and has made it easy to deal with adding new modules.
        now our app runs on Perl 5.8.7 under solaris only. I have read from "perl install" that XS modules under 5.8.* are generally compatible.

        but i do agree with what you said. I think i will go the route of keeping modules local to the app and also keeping a copy of unpacked modules to avoid rebuild for each app. of course a copy of module src.

        in case of change, Krang::Platform seems to be easy to be adopted in our environment.

        thank you.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://552382]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2019-05-21 08:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you enjoy 3D movies?



    Results (131 votes). Check out past polls.

    Notices?
    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!