Development Tools Discussion Group

The mission of the development tools group is to provide a state of the art suite of software development tools that assist software developers to write, test, maintain, and document code for inclusion in the codebase at a velocity and volume not previously attainable. 

These tools are designed to ensure that code improvements are “Safe, Compliant, and Functional”, and include:

Code Repository

The Code and database structure will be placed into an internal master code repository built with the open source Git” distributed version control tool. Initially this Git repository will incorporate all code provided by VA in a directory structure, and provide history of modification to individual routines and globals, allowing developers to use open source tools to obtain copies of the code, and to inspect its history. OSEHRA will push copies of this repository to a variety of mirror sites, where the general public may download and inspect the source code with Git capable tools.  Our first two public mirrors will be on Gitorious and on Github, a “social coding” site that allows anyone to make, share, and discuss proposed changes with the community.

OSEHRA Tools

These tools will include Automated Regression Testing, Stress Testing, Architectural Verification, Interoperability Testing, Section 508 Validation, Standards and Conventions (SAC) compliance, Privacy and Systems Security, Functionality Mapping, Performance Testing, and Customer Satisfaction Measurement.

Instructions for Installing and Testing the OSEHRA Code Base

Web Based Code Review

OSEHR - Software Quality Certification Dashboard

Eventually, OSEHRA's toolset will include CTest and CDash to provide automated checking of proposed changes, and “Gerrit” to provide web-based code review. This will facilitate distributed review of proposed changes by domain experts, coupled with some automated testing using CDash to aggregate test results. Branches of development will be able to be supported at sites using distributed development processes, and later merged if appropriate.

OSEHRA Development Tools Group End State Objectives

These development tools will be augmented to simplify the cloning of the codebase, and inspection of history. The critical aspect of this work will be  augmenting the KIDS subsystem to allow two-way conversion of procedures and globals from the M[UMPS] representation to a canonical on disk format and back again. This will allow for development to continue much as it has for many years and provide an easy path into and out of version control for developers. Once this functionality is present then changes can be uploaded for review, tested in pristine VistA installations and integrated once ready.

FOIA VistA Patches by Package

Group Email: 

development-tools@groups.osehra.org

Chair(s): 

like0

scripts - something went wrong downloading ydbinstall

While yesterday I had manually installed some of the components that the script seemed to struggle with, today, I started over with a fresh box (joy of Vagrant :o). With "set -x" in the bash files, I have more info to go on. And have attached the shell output as a txt file.

I was able to install GTM manually and get a MUMPS prompt yesterday, so I may try that and then "vagrant up --provision" to see if I can get past this. Otherwise I'll work through the scripts and see what needs to change.

Any suggestions appreciated!

David

Vagrant script issue with $PATH

I had this issue with each attempt with Vagrant - can't find MUMPS. Pretty likely it's an issue with the $PATH. Even when I manually entered a path so GT.M would start, other files are unavailable, also due to path issues.

I'll look at it again in a few days, but does anyone know where the paths are set during the install?

Vagrant script issue with $PATH

I had this issue with each attempt with Vagrant - can't find MUMPS. Pretty likely it's an issue with the $PATH. Even when I manually entered a path so GT.M would start, other files are unavailable, also due to path issues.

I'll look at it again in a few days, but does anyone know where the paths are set during the install?

Difficulty getting system up and running

I'll admit to just giving up on virtualbox for now. I had more luck with the Docker instances and will probably try just building in a RHEL virtual machine...

I'm having some difficulty, even though I've followed the instructions to the letter. It seems that Mumps is missing?

$ ssh -p 2222 osehratied@localhost
osehratied@localhost's password:
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-62-generic x86_64)

YottaDB LLC bakes Raspberry Pi

OSEHRA is pleased to share with our community that Organizational Member YottaDB LLC has released YottaDB r1.10. This release adds support for GT.M, on which YottaDB is based, to run successfully on Advanced Reduced Instruction Set Computer (RISC) Machine processor chips, commonly known as ARM. ARM licenses both 32-bit and 64-bit RISC multi-core processors that are designed to operate at a high speeds, and are extensively used in consumer electronic devices such as smartphones, tablets, multimedia players, and other mobile devices including wearables.

scripts - something went wrong downloading ydbinstall

While yesterday I had manually installed some of the components that the script seemed to struggle with, today, I started over with a fresh box (joy of Vagrant :o). With "set -x" in the bash files, I have more info to go on. And have attached the shell output as a txt file.

I was able to install GTM manually and get a MUMPS prompt yesterday, so I may try that and then "vagrant up --provision" to see if I can get past this. Otherwise I'll work through the scripts and see what needs to change.

Any suggestions appreciated!

David

Vagrant script issue with $PATH

I had this issue with each attempt with Vagrant - can't find MUMPS. Pretty likely it's an issue with the $PATH. Even when I manually entered a path so GT.M would start, other files are unavailable, also due to path issues.

I'll look at it again in a few days, but does anyone know where the paths are set during the install?

Vagrant script issue with $PATH

I had this issue with each attempt with Vagrant - can't find MUMPS. Pretty likely it's an issue with the $PATH. Even when I manually entered a path so GT.M would start, other files are unavailable, also due to path issues.

I'll look at it again in a few days, but does anyone know where the paths are set during the install?

Difficulty getting system up and running

I'll admit to just giving up on virtualbox for now. I had more luck with the Docker instances and will probably try just building in a RHEL virtual machine...

I'm having some difficulty, even though I've followed the instructions to the letter. It seems that Mumps is missing?

$ ssh -p 2222 osehratied@localhost
osehratied@localhost's password:
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-62-generic x86_64)

YottaDB LLC bakes Raspberry Pi

OSEHRA is pleased to share with our community that Organizational Member YottaDB LLC has released YottaDB r1.10. This release adds support for GT.M, on which YottaDB is based, to run successfully on Advanced Reduced Instruction Set Computer (RISC) Machine processor chips, commonly known as ARM. ARM licenses both 32-bit and 64-bit RISC multi-core processors that are designed to operate at a high speeds, and are extensively used in consumer electronic devices such as smartphones, tablets, multimedia players, and other mobile devices including wearables.

No questions have been added to this group.

Proposal to use RDF/SPARQL to define Foundation Schema to map VistA elements

At the last Architecture phone call, I suggested using semantic web/ontology technology to describe the VistA architecture, which would give us a formal, common platform for discussing everything required to install and operate a VistA instance.  

Attached is the proposal, which points to the RDFS of the schema at http://www.metavista.name/foundation/foundation.rdfs

 

Proposal

An RDF approach to managing the VistA software foundation

 

Tom Munnecke

Development Tools - Getting Started with Git - Part II

 

This document is the continuation of an introduction to the Distributed Version Control System Git.

The first session of this tutorial is available here:

You are encouraged to go throught the first session before you look at this current one.

No previous knowledge of Git or revision control systems is assumed in this presentation.

Development Tools - Getting Started with Git

This document provides an introduction to the Distributed Version Control System Git.

No previous knowledge of Git or revision control systems is assumed in this presentation.

This is intended to be an easy session to become familiar with the use of Git, following a hands-on pragmatic approach.

 

Once you cover this first introducton,
you may want to continue with the next sessions at

Gerrit Final Review

 

A final review is a necessary confirmation that all required procedures have been executed, the submission is complete, and that the code is ready to be included into the OSEHRA code base.  Only one passing final review is required for a submission and the code contribution can be merged into the OSEHRA code base as soon as a passing final review has been attested.  As such, final reviews can only be made by a trusted individual who possesses sufficient permission to perform the code merge step.

Gerrit Peer Review

 

A peer review is a necessary confirmation that the submitted code is of sufficiently high quality so as to be eligible for inclusion in the OSEHRA code base.  Peer reviews can be made by anyone, and multiple peer reviews are allowed and encouraged; however, at least one passing peer review must be made by a trusted individual if the code is to be considered for adoption. 

Reviewing Submissions to the Gerrit Code Review System

 

Gerrit code reviews are intended to ensure that contributed code modifications and release versions are of high quality and suitable for integration into the OSEHRA code base.  There is no technical differentiation between the two types of review on the Gerrit Code Review site, but we do differentiate them procedurally.

Reviewing Code after Submission

All code review has as its goal the certification of code quality.  The steps and attestations of the review process are similar for all review processes; however, the specific procedures depend upon the review system chosen by the contributor.  To review a code submission to:

  •         The Gerrit code review system

Please refer to Reviewing Submissions to the Gerrit Code Review System. 

To review a code submission to

Submitting to the OSEHRA Technical Journal.

Substantial code contributions such as new VistA modules or major refactorings of the existing code base require a submission to the OSEHRA Technical Journal (OTJ).  OTJ submissions allow for a more thorough description of the submitted code; allow community members to download, use, try, and maintain the submitted code prior to and independently of its eventual inclusion into the OSEHRA code base; and allow for persistence of the submission. 

Submitting to the Gerrit Code Review System

Bug fixes or minor code modifications and formal OSEHRA releases both require submission to the Gerrit Code Review System.  The basic procedures of code submission, including initialization, checkout of the OSEHRA code base, and pushing to Gerrit, remain the same and are covered in “Contributor Git Instructions”, http://www.osehra.org/page/contributor-git-instructions.  In this section, we discuss the differences between submissions designed to modify the code base and submissions designed to initiate the code r

Submitting Code to the OSEHRA Code Base

As noted in the previous section, code developed for inclusion into or evaluation for interoperability with the OSEHRA code base can come in three forms, bug fixes; formal OSEHRA Code Releases; and new module contributions or major refactoring.  These three code submission types are handled by two different code submission processes

Procedures for Contributing Code and Performing Code Reviews

These wiki pages define the concrete steps necessary for a user of the OSEHRA EHR system to contribute code back to the OSEHRA code base, or to perform a review in support of code submitted by another individual.  The process is divided into two sections corresponding to those divisions.  Code developed for inclusion into, or evaluation for interoperability with the OSEHRA code base can come in three forms: