Virtual Labs is a mission mode project initiated by the Ministry of Human Resources and Development (MHRD). The objective of this project is to provide laboratory learning experience to the students who do not have access to adequate laboratory infrastructure. Currently there are around 900 labs developed by various institutes. A streamlined software development life cycle process followed for the development of these labs ensures high quality labs. This document defines the hosting process followed by the developers (open source community) of the Virtual Labs project.
A well defined experiment hosting and on-boarding process helps to maintain a consistent user experience and enables experiment-authors to focus on the content. Consolidated information regarding all the deployments also facilitates reporting.
Vlabs hosting service requires certain prerequisites to be met by the Experiments that need to be hosted:
An Experiment can be a hosting unit or it can be hosted as one of many experiments belonging to a lab or any other experiment group. In such case, the lab or experiment group will be considered a hosting unit. A hosting unit will be hosted in its entirety during a hosting process. It is not possible for a part of a hosting unit to be hosted separately. A hosting unit will correspond to one public repository.
Each repository, which corresponds to one hosting unit, will have one designated owner. The owner is the single entity responsible for all the code that resides in the repo. The owner is also the final approval authority for a hosting request. The owner must ensure that the master branch of the repo only contains the code which is going to be hosted. The latest code in the master branch should represent the hosted experiment. The repository owner does not have to be a person, it may be any uniquely identifiable entity. From the perpective of Vlabs, this entity is the single point of contact for all clarifications. Vlabs will not be responsible for any confusions of issues arising due to shared accessibility of the repo owner entity.
The repository owner is responsible for tagging each merge to the master branch. Vlabs follow Semantic Versioning. In summary, each version is a combination of three numbers (MAJOR.MINOR.PATCH) separated by dots. The changes to these numbers represent the following:
- MAJOR: A change incompatible with previous versions.
- MINOR: A backwords compatible new feature.
- PATCH: A backwords compatible bug fix.
A Vlabs hosting request must specify a tag.
Each hosting unit will have a well defined build process. The hosting service will treat the build process as a black box action. This action will be trigerred to generate the artifacts to deploy. The repo owner must ensure that the build process works and does what it is intended to do.
The hosting process will result in a deployment with an accssieble url. The responsibility of testing the deployments lies with the Repo Owner. The hosting team is responsible for providing the link to the deployment. Virtual labs do not provide any testing environment. The repo owner is responsible for ensuring that the hosting unit works as expected in their own specific testing environments.
Each hosting unit that wants to use the Vlabs hosting service, must onboard with the Vlabs hosting team. The owner of the repo (hosting unit) is expected to provide the following pieces of information at on-boarding:
- A non-conflicting name for the hosting unit.
- Repository URL for the hosting unit.
- A designated repo owner with the following details:
- Repo owner name
- Repo owner github id
- Repo owner email address
- Repo owner phone
- The build command for the hosting unit.
- Software environment specification including:
- Host operating system with minimum compatible version
- Any additional software packages with minimum compatile versions
- Browser plugins required to view experiment
The hosting team will be responsible for storing this information at a central location and making it available for all stakeholders.
Post on-boarding of a hosting unit, a hosting request can be made.
When a repository owner wants to request hosting of a hosting unit, an issue should be raised in the engineers-forum under Virtual-Labs organisation in GitHub. The issue will have the type hosting-request and must have the following information:
- Repository URL
- Branch/Tag to be deployed
- Contact details of the repo owner
The hosting request will be tied to this information. This issue will be a single source of truth for that hosting request. All communication related to the hosting request must be captured on the ticket.
The hosting request will have the following lifecycle:
- After the request is raised, the hosting team will seek its approval from the repo owner.
- After repo owner’s approval, the hosting team will serve the hosting request and send the link to the newly hosted content.
- If the deployment process fails because of missing or incorrect information or Repo problems, the deployment team will update the request status to failed. Failed will be a final request status.
- The Repo owner is responsible for fixing any problems with the Repo and creating a new GitHub issue linked to the failed issue.
- After the hosting request is successfully completed, the repo owner will verify the link and either close or re-open the request.
- A re-opened request will still deploy the same repo and branch/tag. If the repo owner wants to revert to an earlier branch/tag, a new hosting request linked to the original one will be raised. The original request will be marked as reverted in such a case.
- The following information will be stored at a central place for a
quick reference:
- Hosting unit name
- Repository URL
- Currently hosted Branch/Tag
- Previously hosted Branch/Tag
- Date/Time of hosting
The flow diagram depicting lifecycle of a hosting request is below:
- Repository : The distributed version control system - git is used here. Every time the term repository or repo is used, it refers to a git repository. A repository is an on-disk data structure which stores metadata for a set of files and/or directory structure. The whole set of information in the repository may be duplicated on every user’s system or may be maintained on a single server.
- Virtual Labs : Virtual Labs is an initiative by MHRD under NMEICT. The objective is to make engineering education engaging, enjoyable, immersive and online.