Re: What is YOUR Development Process?

[talexb]

How do you compensate for templates, template plugins (I use Template Toolkit (Template)), application modules, instance scripts (I use CGI::Application) and non-application modules being inter-dependant?

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.

The 'non-application modules' are part of a system installation that we track using Red Hat RPMs. That's not easy, but I work with the SysAdmin and we keep that system in check.

How do you write tests that depend on your webserver config (and its environment) and package them with your module?

Because we used a kind of Rapid Application Development approach without tests, we don't have any automated tests for the web application. Yes, I wish we did, and I hope to be able to use WWW:Mechanize to address that in the future.

How to you get your personal machine to emulate the environment of multiple machines?

I don't -- I use a combination of my development system and my test system to develop and test new versions of the web application.

How do you move material to your test server, and from there to production server?

I wrote an installer for the web application that's part of the checked in source. I extract a specific revision from the source control system, run the installer, answer a few questions, do a very small number of tweaks (they're on the ToDo list for the installer) and the system is ready for a smoke test (if this is for a Production system).

Once the smoke test passes, the system is passed on to the customer rep, who passes it on to the customer.

How do you do some of these things in a multi-user environment? (Is the test server a "check out"? Who checks it out?)

I'm not sure I understand your question; 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, just because it's a more capable system than my own workstation for some configurations. That's not a big deal.

Hope that answers some of your questions.

[swiftone]

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).

[talexb]

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".

A web application is a piece of software that runs through a web interface.

I do have multiple instances of my application on a server; each one runs for a specific customer on its own web server, using its own database and directory path.

If I were being awfully clever I could have one set of code and multiple sets of data .. but I don't have to be that clever. Yet.

I'm including CDBI backends, and any other modules we write in the "non-application modules" category. Are you?

Are you talking about a Class::DBI backend? I'm not even sure I know what that is. Can you explain?

How do you select what files to check out? (is everything by itself, or are they tagged as a set?)

After installing (which means I have read-only copies of all of the files), I check out individual files against a specific issue. That makes them writable.

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).

When I'm done testing, I check everything in and ask the Release guy to make a version out of it. That gets passed to the QA person for a smoke test.

We've decided on three levels of builds, development builds (just for me), milestone builds (to mark the completion of a specific set of features and bug fixes) and releases (to mark a milestone that is sufficiently good to give to the customer).

If you have a designer that wants to edit templates, set them up with a userId on your source control system and show them how to check files out and then back in again. If you're on Linux and they're on Windows, perhaps have them ssh in to their home directory on a Linux system, use a command line interface to check files out, then ftp those files home for editting and testing. When they're done, ftp the same files back and check the files in.

[swiftone]

I do have multiple instances of my application on a server; each one runs for a specific customer on its own web server, using its own database and directory path.

If I were being awfully clever I could have one set of code and multiple sets of data .. but I don't have to be that clever. Yet.

I'm that clever now, and it seems to be a source of my problems :) It's a beautiful thing in terms of code-reuse, I can have a separate instance of the same base app with a different appearance just by changing a few meta-data lines and dropping in some changed templates (and usually only the navigation templates, the "functional" ones often don't change). However, the fact that any one "application" isn't a thing in and of itself seems to be the primary cause of my confusion.

Are you talking about a Class::DBI backend? I'm not even sure I know what that is. Can you explain?

Sorry, I guess that's in house lingo. Yes, that's Class::DBI. The application module just controls the state of the I/O and the templates. It's run-modes will call methods on some non-web-based module that does the actual work. It probably calls on Class::DBI interfaces to our databases, and those interfaces are, of course, modules. Respectively we call those application modules, the data modules, and the CDBI backends.

use a command line interface to check files out,

That's been the issue. With the designer not involved in the source control, he FTP files to the server for testing, and edits them on his box (a method _I'd_ find cumbersome, but he's content). He finds connecting to another box to make commits as a cumbersome step, and is fighting it. Since we've failed (from a technical/practical standpoint) at the last two tries to get him in the process, we don't have a strong basis to gain trust from him on this issue.