A day in the life
Perhaps the best way to understand what Razor is and how it will affect your process is by example. The scenarios described here are for a company that offers a nice text editor that already has a couple of major releases in the field. By reading through the following events you may better see how Razor may help out in your environment.
Scenario 1
- The general reception to the recent release of the product has been favorable, but as always, there's room for improvement. Managers, engineers, QA personnel and customers are providing a steady flow of requests for extensions and improvements to the product. Each comment is entered into the issues program which assigns a unique id number.
- The newly submitted issues are periodically reviewed by a lead engineer, who determines the relative priority of each issue, as well as other related information such as estimated cost/effort, scope, etc. The lead engineer may choose to directly assign each issue or leave it in an open job-jar format.
- As an engineer decides to address an issue, he will begin to check out various files from the version control program (versions). As he obtains editable copies into his work area, he will note the reason for obtaining the files through simple prose and by directly relating the issue to the action via a simple mouse/clipboard maneuver. These notes will prove important later as his actions are reviewed.
- During the process, more files can be checked in and out of the version control system, each time relating the actions to the reason (issue) for the change.
- Eventually, the engineer will need to incorporate his efforts into a product build based on related issues. Through the threads program, he can define a test thread to consist of the files which went into the last product release as well as incorporating his recent efforts. This ability isolates test concerns from the ongoing development by other members of the team.
- After some number of iterations, the issue is brought to a close. The latest version of the engineer's test thread can be compared with other threads generated by the rest of the team, files are checked in for the final time, and the issue can be formally signed off. The project thread can then be updated based on the completed issue.
- Immediately prior to sending the next major release of the product to the field for beta test, a report can be quickly generated which lists the issue numbers for those items closed out since the last major release. These can be used to generate release notes, and serve as fuel for metrics analysis.
Scenario 2
This scenario illustrates how Razor can be used with e-mail to track and coordinate changes being made.
- The system is configured to allow customers to e-mail in their concerns or problems. This e-mail automatically creates a new issue, assigns it a unique id number and sends notification back to the customer. E-mail is also forwarded to a project leader whose responsibility is to review the report and assign it to a support engineer. This causes an attached script to run automatically, notifying the assigned engineer via e-mail of the new assignment.
- When files need to be modified to solve a problem, the engineer selects the files to be changed and checks them out for edit. A script is attached to the Check-out Apply button which prevents the engineer from getting the files until at least one issue has been related to the operation and each of these related issues have achieved the proper signature level.
- When the changes have been made and tested, the files are selected for check-in. The Check-in dialog shows the engineer the comments made during check-out and the issues that were related. Any changes or updates to this information can be made at this time. A script is attached to the Check-in Apply button which validates the format of the files being checked in and informs him of any problems with the files.
- Each evening, a batch job runs to parse the database and provide reports which detail outstanding issues, open tasks, files which have been out for edit over a long period, etc. These reports are routed via e-mail to the appropriate individuals for resolution and a summary is sent to the management team.
- Meanwhile, a salesman is at an offsite sales meeting, and e-mail's in a request for the status of all outstanding issues. The query is caught and handled by Razor and the report is automatically e-mailed back.
A sampling of other things which Razor can be configured to do.
- One of the engineers is doing a special project for his masters program and sets up his own Razor database with his own set of rules, attributes, and issues.
- The marketing team sets up a database simply as a job jar in preparation for a big conference coming up, never using the version control aspect of the tool at all.
- A special cooperative effort begins between your company and an affiliate on another continent. You set up parallel issue tracking databases using the remote database synchronization capability of Razor to coordinate efforts.
- Your product is out for field test and an engineer, sent to verify installation, identifies and fixes a bug. Using the remote client and a modem, the appropriate file is checked out, fixed, and checked back in again.
The main point is that Razor is generic enough to meet many needs. It can be used to manage software for a project developing millions of lines of code or control a database of customers or collect favorite recipes. The Razor tool may be tailored by you to meet your specific needs.
