|Think about Loose Coupling|
Templates are part of the web application and get checked in (and I use Template Toolkit as well). Likewise, template plug-ins and instance scripts get checked in.
What do you consider a "web application"? If I have a CRUD app module (as mentioned elsewhere), I can have multiple instances of that module (meaning one physical copy of the module per server, but multiple instance scripts and template sets so that there are several "apps".
The 'non-application modules' are part of a system installation that we track using Red Hat RPMs.
I'm including CDBI backends, and any other modules we write in the "non-application modules" category. Are you? If not, are they "part" of your application? If not (and most of them are not application specific), what do you do with them?
Yes, I wish we did, and I hope to be able to use WWW:Mechanize to address that in the future.
After YAPC I started using Test::WWW::Mechanize, and I can say that it is a huge timesaver on repetative app testing. I can also say that most of my apps don't have a full suite of tests, but as soon as I need to do it, it takes about the same time to write the test as do it by hand, and it's much faster to run again. And again. So you don't need to adopt full testing to get some benefits.
I'm the only developer for the web application, so I don't have to negotiate with anyone for a common file that we both want to work on. I can check files out of the source control system onto the test system for development,
How do you select what files to check out? (is everything by itself, or are they tagged as a set?) What do you do when you're done testing? I have a designer that will edit templates, how would you recommend I get them in on it (they run windows and FTP changes to the servers).