A view from the top

Understanding what Razor is, begins with what it is not. Razor is not a programming "environment." By design, it does not concern itself with the type or purpose of the files being tracking. It does not have any inherent abilities to do impact analysis, analyze code integrity, insure conformity to coding standards, etc. You can, however, add a great deal of this functionality to Razor through judicious attachment of scripts to its actions. In other words, Razor provides the means to make the tool behave in a way that fits your needs, rather than dictating how you should do your work.

Architecture

In its simplest form, the Razor architecture is made up of one license manager, one or more database servers, and one or more client applications (issues, versions, threads, or Razor command line.) A client application communicates with its server, the server in turn verifies the license with the license manager, the server interacts with the database through an archive engine.




Razor records all actions against files in its database; what happened, who did it, when, and what the stated reasons were at the time. All of this information can be queried through very simple means. There are very few restrictions imposed on the users as the tool is generically installed. Razor's natural stance is to allow the user to perform his job while holding him accountable for his actions. Since all information is archived by the tool, there is no risk of losing data.

The database is made up of one or more issues groups, (one or more file-control groups), and a project group. File and thread groups are linked, with a single project group existing for all file/thread pairs in the database. Issues can be related to both version and thread activity, or can stand alone.

Razor and the network

Razor is a networked application. It makes the most of your present network investment and leverages it to your advantage. Razor components can run on a single machine, multiple machines, and across multiple platforms on your network. Below is a network topology where each box represents a user running a Razor application.

Used as a tool suite

From its inception, Razor was intended to address the related concerns of problem tracking and file version control.




Consider that you are at a single, moving point in time. In front of you are tasks to be addressed and resolved. Behind you are the things you have already accomplished. As your project moves along in time, the issues in front of you (hopefully) become your history. Razor helps manage that flow of events and maintains some logical continuity between the two.

In a typical engineering environment, the issues program would be configured to hold all the outstanding tasks for the project team. All issues, no matter how significant or trivial, would be entered into the system. In this way, all members of a team can have a single place to look to understand all the outstanding points. This allows engineers, management, QA personnel, and testers to work in a coordinated fashion.

The versions tool would be used to manage, control, and track changes to files in the project. Changes to files, no matter how insignificant they might seem, would be associated to issues.

Finally, the threads tools ties things together by gathering specific file versions, as controlled by the versions tool, and associated with project issues, tracked by the issues tool. Repeatability in project build, test, and release are essential elements in solid engineering practices. Razor provides these functions in a consistent and integrated fashion and is highly customizable to your requirements.

Used as independent pieces

Razor does not have to be used as described above. A great many sites have found the tool to be very effective for just tracking problems. Others already have existing solutions for problem tracking, and use Razor just for its file version control and build management capabilities.

There is nothing forcing you to use Razor's entire functionality, and the programs will work independently.