TN-01 : Development, Test and Deployment process for Virtual Labs(Deprecated)

From Virtual Labs Community
Jump to: navigation, search

This document describes the guidelines and instructions for developing, testing and deploying a virtual lab.

Process approach to building virtual labs

Building a virtual lab involves several related processes:

  • development process: involves

development of content and s/w.

  • test process: involves testing

the s/w and content on a local web server.

  • deployment process: hosting the

virtual lab on a server accessible to students and others.

  • evaluation process: the process

of evaluating the labs by the experts.

  • field testing process: the process of capturing the

feedback from students using the lab.

Development Process

Development process.png

Development Server

Each lab development team has a login account on The developer(s) may use this server primarily as a version control server.

  • Login account is cse<nn> where nn is your lab number.
  • Keys have been already mailed.

Mailing List

The mailing list is

To subscribe, send a mail to

SVN Repositories

On this server, the lab may run its own svn repository. There is an svnserve process running on Alternatively, developers may access their svn repositor(ies) via svn+ssh. Sorry, we are not supporting git or mercurial yet.

Development Process

Lab developer responsibilities:

  • The primary lab developer needs to supply the url of the labs and each experiment.
  • The primary lab developer is the point contact for all communication with the DNC about the lab.

Building the virtual lab

The end product of the virtual lab development process is a directory called build under the lab developer's home directory on the devel server.

Working with UI Templates


It is important that the development of lab content be done as independently as possible of any tool or specific database, and instead conform to web standards. The following process specification outlines how a lab developer can use a w3c HTML-5 compliant content template along with modular and customizable themes.

The advantage of this approach is that

  • Content can be developed indepent of style considerations
  • Different themes can be experimented with and used.
  • The modularization allows for automated ways to combine the content with themes.
  • The modular approaches is more lightweight and efficient: there is no need to install special s/w applications or databases.
  • There are no dependencies on proprietary s/w, Operating systems or databases.

User interface installation and generation of lab deliverable

Please refer to the following document TN-02 : User Manual For Lab-Deliverable Tool Kit. It explains the user interface installation in detail, and the process (sequence of linux shell commands like make) needed to generate a lab deliverable.

Test Process

Test server

The test server is only accessible via ssh from devel via the command:

 ssh  test

Remember, you need to be logged in into devel to run the above command. (Use -i flag while ssh if it asks for password)

Migrating the build to the test server

 scp ~/build test:public_html

Essentially, anything under public_html will be visible

Testing the lab on the test server

The test server already has a web server on it. To test the build installed under public_html, point your browser to<nn>/build/

Deployment Process

The deployment process is automatic and the only thing the developer needs to ensure is the presence of the lab application under a directory called ~/public_html/final-build.

Everything under ~/public_html/final-build and only that will be deployed.

The canonical url for the lab will be<nn>

Evaluation Process

  • If you are planning to deploy your lab on your own, please send us the url. Otherwise, we will assume that your lab is accessible through the url.<nn>