That's what I would do.

That would solve all the updating issues, bu where do you draw the line?

When the drawbacks outweigh the benefits, you copy and paste what you need and start a new project.

If I put the instance scripts and templates in the same tag as the app module, I can't install the app module on another machine without installing the instance, which is not desired.

Make a config file that says which instance to use. Install all the code, even if you only need 5% of it on a specific machine. Anything else will lead to dependency nightmares.

Okay, we've looked at that model. The problem was trying to keep development from clogging up production. Quite often we'll start on development and get pulled off onto other projects, leaving code incomplete, sometimes returned to, sometimes never returned to.

Do that unfinished work on a branch. Use a separate branch for each project. Merge the trunk to the branches periodically. Merge the branch back to trunk when you are done.

Here I'm missing details again. If we're checking out the entire codebase, are we running every bit of test code we have? How do we do the install process so that only the changed bits of code are tested on the new machine?

Since you're describing a codebase with lots of reuse, you have no choice but to test it all, to make sure you didn't break an older app. Don't try to test "just the changed bits." Regression testing is about testing it all.

(Anyone with advice on what to do with the Windows designer who edits our templates would be welcome, since he can't test his edits on his machine.)

In most cases, it should be possible to make your code run on Windows. If it really isn't, the best approach is to have a test server (web server, not a whole machine) dedicated to your designer, with the templates on a samba share that he writes his files to. That's nearly as transparent for him as running it on his own machine.

Really, I'm not disagreeing with good practices, I'm just trying to figure out how to IMPLEMENT them.

You need to explain to the people who could finance the purchase of test servers, load-balancers, etc. what the risks are that they are taking. They might prefer to have some bugs and some downtime in exchange for saving $10K on hardware, but then again they might not.

• Re: Yet another "why CGI-Application" question
• Re: Structuring multiple CGI::Application modules II
• Re: Why CGI::Application? (This whole thread is really good)

I don't think you're leveraging the greatest benefit of CGI::Application which is the parent class. Each of these different apps should have their own CGI::App child class, using a set of parent classes which would be shared across all your different apps. That's where the reuse comes in.

I don't think you're leveraging the greatest benefit of CGI::Application which is the parent class.

Actually, I'm leveraging it more than the average CGI::App user. I have a CGI::App subclass that manages my framework. If I have an app, say, a CRUD app to manage contact lists, it exists as a subclass of my framework class, and might have 5-10 instance scripts. Should I have a peculiar version, sure, i'll subclass it and have some particulars, for for a lot of apps only the templates and the names of some fields change. So I reuse the parent class. A lot. More than most CGI::App people, based on my questions in the past few years on that mailing list.

I'm not clear on what you're suggesting that I'm not doing.

You were mentioning that developer A produces version 1.0 of some C::A subclass for application Foo. Then, developer B comes along and upgrades that same C::A subclass to version 1.1 for application Bar. All of a sudden, application Foo doesn't work the same.

To me, each application should have its own subclass, even if that class is nothing more than

package Our::Web::Apps::Foo;

use base 'Our::Web::Apps';

1;
[download]

If only to avoid the problem that you're discussing.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Yes, all developers check out all code at all times.

Keeping development from getting messy is a matter of keeping it always clean. Try to work in small projects so that what's checked into the head of development is always theoretically good to go to production. Push it to production regularly because it is easier to test many small releases than a few big ones. If you absolutely must do a bigger project, create a branch for it then merge that back into the main tree when it is done.

The amount of code is a non-issue. Suppose that you have a hundred thousand lines of code. What is that, 8 MB, plus maybe another 10 MB if you have a bunch of images. I think modern disk drives can handle that much code!

The bit where I was talking about installing version X of Foo on machine Y was a case where Foo was an external module (eg from CPAN) which is not part of your source control. Such as a DBD driver that you need.

What do we do during an install process? Lots! Here are some of the steps:

• Check out the tagged version to a local machine.
• Re-run tests.
• Copy code to the machines where it needs to go.
• Restart webservers.
• Install crontabs. (Everything that is critical to your application should be in source control!)
• Send an email to various people saying that we pushed to production, and summarizing what was pushed. (That summary is pulled automatically from version control commit messages.)

While having a separate test server is a Good Thing, you can (if necessary) live without it. If you've set things up so that all paths in your application are relative to the application root (which can be made findable in various ways - an environment variable is a convenient one), then there is no problem having multiple copies of your codebase on one machine. (Hint: It helps to have a configuration module that allows per user instances to run on different ports.)

Assuming that you've done that, all that you need to do is select a developer machine and say that it is also the test machine. Create a test user, set up ssh keys so that all developers can easily ssh into that machine as that user, and put your test codebase in that user's home directory. (One way to identify a test codebase is to have a revision tag, eg stg, which is the version of the code that is currently in QA. The test codebase keeps checked out whatever has been tagged stg.)

Now even though you don't have a test machine, you have a standardized test environment. Is it as ideal as a real test machine? Of course not! But it is a heck of a lot better than nothing!