If you have to alter files post-production, you should do that in the templates and alter the (one) template, or use the <TMPL_INCLUDE feature to build your templates from smaller parts. Consider creating your Javascript files from templates as well. You don't need to render the templates live ("fry"), you can just create them on a new release ("bake") and then copy the resulting files to a static directory on the webserver.

I don't see any version control making this simultaneous editing easier. I'm fond of git, because it has very little administrative overhead.

Seconded. the wonders of github also make sharing/access easier. Corion's advice about static releases is good advice too - OP doesn't want to get sucked into cycles of releases and bufixes. Making static releases I always find makes you *think* more about the release, which is always a good thing...

Just my too sense.

Just a something something...

I'd have to install git locally, can't use github online from our servers. Thanks

Will git take the pain out of rolling things out? I have multiple sites over two test environments and a live environment?

Not better than any other revision control system. I would do the distribution through rsync or some other distribution mechanism. Just check out the "tested good" state and use rsync to distribute it across all machines, or directly check out the "tested good" state on each machine through git, depending on your network setup.

Although you can use a version control system when deploying stuff. But that's not the task of version control system, and you'll have to do some manual bookkeeping (or write a wrapper around that).

Given that you only have a tiny system (from your other post, I get the impression you only have 3 systems), you could use git. Check it in in your dev system, and pull from your servers. Yeah, that may require typing in 'git pull' on three different machines.

Alternatively, use git (or some other version control system) to track your development. When ready to make a release, create a package (either native to your OS, or one that has a toolchain for your OS), and use cfengine, puppet or some other tool to roll them out.

Or just roll out the sources on one box, and use rsync to update others.

"There's more way to do it" isn't exclusive for Perl. Not that your question was even remotely Perl related.

As JavaFan points out, packaging-systems and version-control systems are not the same thing.   Be sure that you have a clear understanding of the differences, since it is likely that you will be using both.

If your servers are distant from one another, or not fully under your control, then a reasonable strategy is to prepare a distribution-package to install upon each of them.   The package would be designed such that any and all of the necessary changes will take place in the process of installing the package.

An alternate, or companion, strategy is to use version control directly.   On each server (perhaps as a regularly scheduled task?), you “synchronize” the production code libraries on the server with the latest (appropriately labeled as such...) production branch.   The servers only synchronize (themselves) with the designated branch:   they never contribute any changed code to it.

I say, “companion strategy” because, as you can see, you might need to do both things.   Version-control might be used to synchronize-out a set of packages to all of the servers, which then must (automatically?) “install” those packages.

As always, check CPAN first.   Do a thorough search for existing modules that will do all or part of what you want to do.   (No matter what it is that you are doing, it has probably been done before.)

First, if you are running any kind of a production system, you need version control. Not just because it makes it easy for the programmers, but because it makes it easy for operations to roll back changes if they're bad. With version control you have the option of being able to precisely undo or redo any change you've made - this can be really handy if (say) you've added a new feature, which works fine, but messed up a configuration setting. With version control, you can back out the bad stuff and keep the good (most of the time anyway). Git is great; we're using Mercurial is also very good. Subversion is an option, but git or Mercurial will probably end up working better for you. Even rcs is better than nothing for a solo developer.

Second, you need strongly to consider a staging system. This allows you to pretend you pushed the code to production and then try it. Often you can manage this with a virtual machine if you don't have enough servers to let you try things live; you may need to create a test database (for example) to make sure you have all te resources you need to run. I've had pretty good success with VirtualBox - it's easier to get running than Xen or VMWare, at least for me.

Third, you need a test suite. Unit tests and integration tests which are run when the build is done, and "live" tests that hit the server and verify that it's doing what it should be doing. Selenium is a very useful tool for testing web interfaces. If you have a REST server, you may be able to use WWW::Mechanize to test the backend. If you also have a custom client, Mojolicious::Lite is a grand way to put together a mock server that can send the data you expect, as well as fail predictably so you can test your client's error handling.

If you have all these, then you can consider using a continuous integration server (I like Hudson for its flexibility and easy of deployment) to monitor your version control repository and automatically check out, build, test, and deploy to staging whenever a checkin is done (or on a fixed schedule, depending on how quickly the codebase is changing - you of course have the flexibility to only deploy once a day, etc.).

The key to good deployment is to have a simple (hopefully scriptable) deployment process. Every manual step in a deployment adds to the possibility of a failure or error. Staged deployments will, most of the time, allow you a simple way to check your deployment before you push it live.

One final thought: if you can manage it, try to create a design which integrates directly into the OS on the deployment machine as little as possible. Use local::lib, or build your own Perl, to ensure that OS updates don't end up breaking your code. In addition, if you avoid integration, you may be able to use a "twinned" deployment: two copies of the software, one the "live" old version and the other a not-running new version. You can then shut down the old system and bring up the new (barring database migrations, for instance) without problems.

Anything that could destroy data or transform it in a non-recoverable manner requires extra steps to back up the pristine data and restore it if necessary. You must test this prior to the real deployment to make sure you're not crossing a line of no return. There's nothing worse than migrating to a new setup only to find you have a really bad bug that you didn't find in testing, with no way back to the old system!

I seem to have written an entire essay on this. Perhaps I should copy this over to Q&A or Meditations...

Yes, you should...

I would like to “resuscitate” this thread (making note that there is also a good Meditation that was coalesced from it...), to specifically ask for insights about a particular situation that occurs here.

The app that I am dealing with now runs on about four different (AIX) servers ... database servers, HTTP portals, and SAS-eating monsters.   When “a new release needs to be pushed (from git ...) to The Server,” well, there are several of those servers, each one of which is concerned with only the parts of the overall source-code which need to run on that particular machine.   None of them ever need to see all of the (rather-vast) source code.   When we will be updating the servers, each of them will need to be pulling their own particular source-code sections from the repository and putting them in place.

Hence, I am wondering how any of you who have had to deal with that familiar situation ... found it best to organize the staging-files in git.   Specific links and references (other than the obvious RTFM-suspects) are warmly welcomed.