Note: You can contact Visible Systems Corporation Sales by calling 315-363-8000 or sending an email to razor_sales@visiblesystemscorp.com
The license agreement may be found at: https://visiblesystemscorp.com/Products/Razor/license_agreement.htm
Note: Managing users at the Active Directory, LDAP etc. levels are managed at their source.
Note: When importing a Razor 5 password file, the file must have read permissions and be accessible by the Administration Tool
The Razor Agile Desktop is the gateway to all of the tools that are available to the user along the left had side as well as the Applications pull down. The buttons along the bottom provide information on the release via the About button, details on the tools via the Details button and the Exit button exist the Desktop.
One can use the TAB key to navigate through the selections or press the ALT+ the Letter for the desired functions. Pressing the enter key will select the highlighted function.
This tool allows for the selection of the Razor Server to contact in the event that your Razor administrator has set up more than one, the Project to connect to and presents all available local host IPs to use for commutations to the Razor Server. As before use of the TAB key and the arrow keys make the selections quick and easy.
In the case that the Client detects thaty the database is down or may have moved, the following screen may be displayed. Please read it carefully and contact your Razor Administrator to see if the Database id offline or has moved
Razor Agile now has Superset to Issues that incorporates Agile Software development. This system uses Sprints and Stories to provide greater insight into the development process. It even incorporates rapid releases in the form when a story is completed, the Snapshot for that story is automatically updated with all the files worked on and associated to that story.
When selecting Sprints for the first time form the Razor Agile Desktop the following screen may be displayed
The default is yes and if yes is selected the following screen will be displayed
This part of the Sprint System ties any completed story in a sprint to a release in Razor Agile which then if desired can be automatically deployed via Scripting to production.
Once all is complete the Main Sprint Page will look like this
Double clicking on a new Sprint will bring up the following
Click on Yes and this screen will appear
Since Stories are Issues the Brief Description will be translated into the title of the Issue and the Detailed description will be translated into the Problem Statement
Once submitted the Story Board will show up and look a bit like this:
Double clicking on any story on the Story Board will bring up the associated Issue
At this time, Razor Agile does not have a role per say called a Scrum Master. However, one can be set up in the Roles and Permissions Tables which will be discussed in the Appendix on how to implement.
Razor Agile’s Issues functionality remains pretty much the same as Razor Classic’s Issues. The main Issue form is completely redesigned to make selecting items quicker but the old methods for selecting items remain
Since Sprints are intergraded into Issues there is a selection to show Sprint based Issues only
These are descriptions of the righthand controls. Some of these like the Change Group and Change Project have the same functionality as the Groups and Project Selection on the Menu bar.
There are addional options with the View and Commands selections on the Menu Bar. However, the Command selections are only available if your Razor Administrator has set them up for you. These are usually scripts or other programs that provide additional functionality to the Issues System
When an Issue is submitted the form will look like this:
The State field shows that the Issue is Submitted with it’s Priority set to High. There are no attachments at this time and the full title is displayed.
The Issue form that is included with Razor Agile is very basic but it is a good starting point for new users.
The Issues form features what Visible Systems calls a state driven guide to filling out the form. If you notice in the form above, several fields are grayed out, but already filled out and some are open and have a yellow background color.
There is a table in the database that drives the field guide that is called the Insensitive table. This table along with the roles and permissions tables can hove profound affects on how a user is guided in filling out the form. This can be used to ensure a consistent and repeatable process for describing a problem to the actual fix that was applied to the problem.
What this means as the states (Submitted 🡪 Approved, or Submitted 🡪 to Rejected) and so forth are changed, different areas of the form are opened up or closed off as needed by your process.
The setting up of these tables will be discussed in the appendix of this manual.
Here is an example of a submitted Issue set to the Approved State
Notice that new fields have been opened up and highlighted in Yellow. Also, the Activity and Attach buttons are now available and will be discussed below.
Once the form is filled out the submit button is selected and the database is then updated with the new information and the main display is refreshed.
When an Issue is set up to be required to interconnected with Versions and or Baselines the Activity button will provide insight as to what the issue was used for.
In this case this issue was used to Introduce files into the Versions system. It provides additional information as to Who and when the files were introduced and which files were introduced.
Sometimes a problem that an Issue must address is too complicated to be expressed in the Description of problem section or some other supporting documentation is required for final approval that all fixes have been properly applied before releasing the code to the public is approved. This is where attachments come in very handy.
Note: Removing a file will not remove it from the display. It will be highlighted as removed but it’s history will remain but can no longer be downloaded or viewed.
The versions program is the backbone of the configuration management aspect of the Razor tool suite. Versions provides a straightforward mechanism for controlling, monitoring, and archiving changes made to files in your development environment.
These are descriptions of the righthand controls. Some of these like the Change Group have the same functionality as the Groups Selection on the Menu bar.
There are additional options with the View and Commands selections on the Menu Bar. However, the Command selections are only available if your Razor Administrator has set them up for you. These are usually scripts or other programs that provide additional functionality to the Versions System
As one can observe, the directory is now showing up on the Versions Screen. By Clicking on the plus sign, the directory is opened and all the files are present.
Razor attempts to learn the file Icon that is associated with the file type. In most cases it represents the file type quite accurately. One will also note that each of the introduced files are assigned a revision code 1.1. Even though the file is “introduced” into the Git repository, Razor Agile tracks the file revision / hash code for each file for a more human readable format. The importance of this will become more apparent as you read on.
By double clicking on any text-based file a read-only display is presented of that file’s contents. Note if the file is a binary file a warning message is displayed, but not the file contents.
Also, by selecting a file and then selecting Utilities 🡺 Info the following is displayed
The file history will show in detail every action that has taken place on that file. When and who checked the file out for edit or read-only etc.
The Utilities 🡺 File Diff will be discussed below.
There are times where a developer may need to get a copy of a file for use in another project or just want to get a print out a better view of the file.
Simply select the file and then select the Check Out Rad Only button
And the following screen is displayed
The file name and directory are displayed as shown. The browse button is used to select where the file is to be written. In this case M:\
If the Path is absolute is checked the directory structure for the file is removed. The file location is in this case M:\ActivityTest.sh
The Available Versions pull down is unique. If left as show above, the latest version of the file is received from the Git repository, However, if there are many revisions on the file i.e., 1.1, 1.2, 1.3 then selecting one of those revisions will get that file version from the Git repository.
Now the work begins. An Issue or Story from a Sprit has been assigned to you. Time to get the files needed to begin work. The process is started by selecting the file or files needed and clicking on Check Out for Edit Button
Once the form is filled out as shown below click on the OK button and the file will be checked out and assigned to the person doing the check out
Once the file is checked out the person who has the file checked out is displayed on the main versions screen
Now if you remember the Activity file, it now looks like this:
It shows that the file is checked out, by who and when.
Also remember the Info file, it now looks like this:
After files have been modified, they must be re-entered into the database. To do so, the user first selects the relevant files from the main display of the versions program and selects the Check In button.
Under File Control one can select what is to be done with the file. The default is to Leave a read-only copy in the location of where the file was Checked out to and is the recommended action. Take the files will bring the files back into the Git repository, then delete the files from the location where they were checked out to. Check the files back out for edit is not currently implemented at this writing.
Now if the Razor Administrator has required that the file must change for a check in and the file was not edited, the following screen will appear
And nothing has been done, the file remains checked out
If the file was changed and checked back in the Versions main display will look like this
Note that the file revision has now been incremented to 1.2. The changes to this file are reflected in the Activities and Info displays respectively.
Razor does not come prepackaged with the Guiffy Diff tool bit it pre licensed for the tool. This is a major change from Razor Classic which allows the user to upgrade the Guiffy tools as needed and not have to wait on a new release from Visible Systems.
Here is the process to execute a diff on the file we just updated. First Select the file, then Utilities 🡺 File Diff
The Main Diff form will show up. Here is an example with some info
Once the selections are made for what is to be shown and which versions to compare click on Apply
This screen will appear if you have not yet installed the Guiffy tool on this computer
If you select No, a very basic diff tool is used to display the file differences
If you select yes, you will be taken to the Guiffy Web site and please download the 64-bit version of the tool. You DO NOT have to request a set of temporary keys as Razor Agile is pre licensed for a full version of the tool. Install the downloaded file and please do not change any of the default settings. Now click on apply and a new display will appear
All options on the tool are available to the user as needed.
Branches are deviations from the main development line for a file. They are a convenient mechanism for allowing two or more people to be working on the same file at the same time (perhaps for different goals).
A common scenario is having one person working to add new features to the product, while a second is doing bug fixes on prior versions
The version numbers of branches can be a little confusing, and warrant a quick discussion. Version numbers on the main development line have only two parts; a major and minor number.
Branches have 3 parts to their numbering scheme. The first two parts represent the point at which the branch split off the main line. The third number indicated the branches revision level.
Looking at the main Versions page, we discover that Mike C has the file we were tasked to work on already checked out. We need to Brach this file. We begin by highlighting the file then select the Branch Button
The Branch form is pretty strait forward. It requires the selection of the file version to branch, a reason for the branch and a description. Then assign an Issue for traceability and then select OK.
The main Versions Page now looks like this
The Branch can now be checked out edited checked in checked out again to continue editing just like any other file on the main line. Likewise, the file that Mike C has checked out can be checked in and checked out again so there are 2 independent development paths for one file.
It is expected that branches are used as a temporary means of allowing concurrent development on a single file. Sooner or later, the edits made to the branched line will be incorporated into the main evolutionary line for the file.
To begin the process of Terminating a Branch, the main line file and the Branched file must both be checked back into the Razor Database.
To signal the end of the utility of a branch, highlight the branched file in the main scrolling list and select the Terminate Branch button and the following will appear
The default is Yes to merge back into the main trunk. If No is selected, then the Branch is terminated and the code changes are lost.
Selecting Yes will bring up the following for Traceability for the Merge
Select an Issue to this Merge and Select Okay
There are 2 options for the merge. Method 1 brings up the Guiffy GUI, if installed, to help visualize the code that will be merged into the main trunk. The user has the ability to accept or delete lines that may or may not be needed etc. prior to the merge completion.
Method 2 is allowing the Guiffy tool to automatically resolve the merge of the 2 files and create an amalgam of the two. In either case once the merge is complete the main trunk is automatically checked out the newly merged file is then checked in and the revision of the main truck is bumped up one
The Baselines program is the final piece Razor Agile. It provides a mechanism for defining which unique combination of files and versions "belong together" for the sake of a release or product build. This section discusses how to use the Baselines program from a user's perspective.
Within Razor Agile, a "group" is an organizational model. The Versions program allows you to define which files belong within which groups. All files in the same group are assigned a similar set of attributes, although the attribute collection may vary from group to group.
Although the Versions program provides a nice vehicle for monitoring changes on a file by file basis, it's often necessary to monitor changes to your effort from a broader perspective. Your product at any point in time is defined as the union of a unique combination of files, at a unique mix of their relative versions.
A Baseline or Snapshot can be thought of as a collection of specific files that have been grouped together for a special reason. One reason to group files together into a Snapshot is for release/build management. As new releases of a product are developed, the files (implying specific versions of those files) are gathered together, tested as a whole, and ultimately released as a whole.
The exact state of each file, as they relate to the Snapshot, can be reconstructed. A Snapshot is what forms the relationship among specific versions of files. Files are no longer thought of as individual, autonomous entities, but rather as what the combination becomes. An individual source file that performs mathematical calculations by itself is not worth much until it is packaged within the context of a system.
If we imagine a simple group containing only four files, then we could diagram how each file has evolved from version to version, as well as how Snapshots come into play.
Each row of the above diagram shows how a single file within the group evolves from version to version. The vertical (blue) lines which flow behind the rows represent threads. Each thread indicates a relationship of which file/version combinations belong together. For example, the left most Snapshot on the diagram brings together main.c:1.6, init.h:1.6, color.c:1.2, and static.h:1.9. The only difference between the second and third Snapshots on the diagram is that they reference different versions of the file color.c.
The meaning and utility of a Snapshot is completely up to the user. Each Snapshot may be given a unique name, and may evolve over time. The diagram above may be represented as four different named Snapshots, or a single Snapshot that has gone through several changes itself. Often, each Razor group will have a Snapshot which defines the file/version combinations constituting a product shipment or release. This special Snapshot evolves over time to reflect the contents of each release. Separately, Snapshots may be defined to remember which combinations were compiled for the sake of lab testing, or to create a test mix of files for quick experiments. The scope and utility are completely up to the user.
These are descriptions of the righthand controls. Some of these like the Change Group have the same functionality as the Groups Selection on the Menu bar.
There are additional options with the View and Commands selections on the Menu Bar. However, the Command selections are only available if your Razor Administrator has set them up for you. These are usually scripts or other programs that provide additional functionality to the Baselines System
Once files for the project are intorduced in Razor’s Versions, and some editing has occurred along with some basic testing it is time to create the forst Snapshot of the current state of the code.
It begins by clicking on the New Snapshot button on the main Baselines form.
These Environmental Variables are created by the server when a script request is detected by the server. They should not be changed at any time by any scripts unless noted below
The API for Razor Agile contains 2 types of commands. Those that do not involve the entire server engine and those that do not. The commands that require the server engine must include the keyword “console” as show in the following items
To execute these standard commands in the console, first start a Windows Console and then enter: cd c:\Program Files\Visible Systems\Razor Agile Server
Once there enter the commands as listed below:
To execute these standard commands in the console, first start a Windows Console and then enter:
cd c:\Program Files\Visible Systems\Razor Agile Server
Enter the desired command in as follows: Razor6Server.exe id
The command will display the output on the console.
To run the command via a script, see the next section on Interactive Commands
Running Server requests from a Script no matter what type the user must inform the server that it is to run the command in “console” mode. This is because the Razor Agile Server is running as a service and services cannot normally be accessed from a command line. However, by using the past parameter when calling a RazorService command the server will execute the command and return the results to the Script.
Something to note here is that the error paths return a robust parcel of information back to the script. It may make it more difficult to test for this information, however it will indeed speed up development of a script as the programmer will know what is amiss in their script.
One last thing to note. The system_setup script supplied by Visible Systems Corporation and installed when the server is installed is for the most part complete and tested. But, if while developing scripts and you are required to update any of these, please send the updates to razor_support@visiblesystems,com so we can include them in our next release. The install program will overwrite these locations.
Visible Systems is providing sample scripts for your use and or modification. Each script will demonstrate the proper calls and return values. These scripts are contained in a ZIP file which can be downloaded from this location: http://fileLocationhere
Once downloaded, unzip the files in a desired location. Next if on Windows use the File Explorer to navigate to where you unzipped the files, then Right click and select Git Bash Here option. This will bring up a Git Bash Shell it will look something like this:
Note the directory format: /e/SampleAPIStuff. If you are going to specify file locations within a script this is the format to use. E:\SampleAPIStuff will not work at all.
Next you will need to set the RAZOR_HOME path. So, enter EXPORT=” C:\Program Files\Visible Systems” and press the enter key. At this point, open any of the scripts in Wordpad or the editor of your choice, yes vi works here too and read the script’s passed parameters requirements.
Each of the tools in Razor Agile with the exception of Sprints has available to the user the Command pull down in the main tool bar. If your Administrator has made commands available to the user this is where they will be available from. Sprints do not have a Command Pull Down available as they are a super set of Issues and can be worked with within the Issues Tool.
Exit codes for Command scripts
There are three exit codes for these types of scripts:
On the return code 1 to return a message to the user it would look something like this:
#/usr/bin/bash
echo “This is a test
And we are adding a second line to that test”
exit 1
Usage:
Preload File Usage Example:
Note: The Attribute (Originator) and the Result (RAZOR_USER) are separated by a single tab
echo "Originator
Passed Parameters Usage Example:
This is for 2 passed parameters in a comma separated list.
(PassedParam1, PassedParam2)
If [[ -z "${1}" ]]
else
Format for passed result is as follows:
$updateThisAttribute, $item1, $item2, $item3
Where $updateThisAttribute is the item that is to be updated within Razor followed by a comma
and the items values to be used for the update separated by commas
echo $result
Passed File from server to scripts usage Example
This file will contain a formatted Issue, full file from versions or Baseline output
It can be parsed within the external script as any normal file would be
# $1 is the file path to the passed file, in this case the Issue
# The fourth item in the file is the issue name which we need to
# Get so this is one way to do it
ISSUE=`"${sedexec}" -n '4p' $1`