Managing Assets

I l @ ve RuBoard

Managing the assets of a project over time can cause problems if not attended to early. All assets, including code, unit tests, graphics, diagrams, and the like, should be stored in one location, which should be governed by revision control software (RCS) such as CVS or Visual SourceSafe. In traditional software development, users check files into their own sandbox on the customer's computer or a directory on the server. In Web projects the development area needs to have a virtual directory for every team member.

Using CVS versus Visual SourceSafe

Most of our experience has been with CVS. It is a great tool because it is free, it has customers for multiple OSs, and it allows builds to be easily scripted with tools like Ant. Nevertheless, we are most comfortable working in Visual SourceSafe because of its close integration with Microsoft IDEs. Either product will do the job, but we recommend CVS for Java projects and Visual SourceSafe for Microsoft projects.

Users check files into their own sandbox in traditional software development

All projects should conform to the same coding standards and file and directory naming conventions. Everyone should know what to call things and where to find them.

Web projects rely on an HTTP server and often an application server. Programmers need to see the results of their work instantly, and they can't be expected to check their code and do a build every time they want to see the results of a code change in a browser. Moreover, we cannot expect team members to run a Web server and application server on the customer's machine. Have you seen the licensing fees for some of these application servers?

The virtual directory that belongs to the user on the server needs to contain the complete Web site from the last working build and the files the user has checked out. Work in progress from another user should be kept in another virtual directory. All users should be able to make a change, save it without checking in, and reload their Web page to see the result.

RCS manages the checkin and checkout of files and can create a complete set of files from any point in time. A fully functioning copy ”that is one that has passed all unit tests, Linkbot, and other automated tests of all the project files ”is sent to a quality assurance (QA) folder for review.

QA reviews the site and uses a defect-tracking tool like Bugzilla to track errors and report them to the development team. Defect-tracking systems allow testers to report their finding to the team and track revisions from one "cut" (version of the project) to the next . Remember that the customer should be very much involved in this process. Bugs such as system crashes and bad data should be caught and fixed before the code ever gets near QA. If not, and these kinds of bugs are creeping up, you have to go back and write more unit tests. For defects that make it through QA, the customer should decide if they will be fixed or left alone for the time being. Every hour spent to fix a bug is an hour that could be spent on adding more functionality. The customer is the sole arbitrator of what is good enough!

It is true to say that automated testing on Web projects is still in its infancy. We can effectively test that all links work and that functions run correctly. XSL goes a long way to ensuring visual consistency throughout the site, but we are still overly reliant on human beings to say that everything is visually correct.

I l @ ve RuBoard