Local Mobile App Development

Getting Started

VA app development can begin on local computers outside the VA network using a Mobile App Platform (MAP) Docker solution. Developers install the following technical stack:

• Git Bash
• Docker Desktop
• A hypervisor like HyperV or VirtualBox
• Kubernetes Minikube

About the Kickstarter Program and the Starter Kit

The WBM (WMS Build Management) team maintains the latest prerequisites and instructions for installing a local environment in a Windows-README.md and other documents located in the Docker Local Development Repository. As developers employ the WBM Docker solution, the WBM reviews them and, if approved, adds them to the Docker Trusted Repository (DTR), which development teams can use as starting points for their own projects.

Once familiar with the VA Mobile Framework build platform and the VA Mobile App Compliance Requirements, developers implement a MAP Docker Starter Kit to move their projects into the MAP Sandbox environment.

The MAP Sandbox Environment

Once an app development team completes creating an app locally from the WBM Starter Kits, obtain accounts to the Sandbox Active Directory, they then deploy their containers to the VA External Cloud Mobile Application Program (VAEC-MAP) Sandbox.

The Sandbox is identical to the later MAP environment except that, for safety, it is not part of the VA network. Developers test their apps to see how they would work if they were on the VA network. They also gather all the compliance artifacts they need to pass Verification and Validation (V&V). In particular, an app cannot deploy to staging until it has an approved System/Service Design Document (SRVDD/SDD).

Deploying and working in the Sandbox is similar to the local development Docker-Kubernetes environment configuration. The main difference is that the build and deploy scripts run on a Jenkins build automation server. Deploying to the MAP Sandbox has the following advantages:

• Reduces environment dependency: Reduce the dependency that development teams have on any one particular environment by providing the capability to launch and terminate them at will.
• Better resource utilization: By terminating environments that are no longer being used, capacity is freed up for other development teams.
• Knowledge transfer: When team members know that their environments will be terminated at specific times, automation becomes the only solution to the institutional knowledge of how the environment gets configured.

These are some of the functions developers can add to their apps once they reach the Sandbox:

• Create namespaces with the "create-namespace" Jenkins job
• Manage Consul and Vault values for testing
• Create Kubernetes pods
• Connect without VA VPN access
• Run builds
• Deploy apps
• Create databases (MongoDB, Oracle)
• View application logs in Kibana
• Integrate with mock VA services to control test scenarios and data (the Sandbox has no connection to real VA services)

Sandbox Requirements

Deploying to the Sandbox environment confirms that the development team has tested for the following issues:

• Application automation works (including automated testing)
• Application environment is created properly
• Jenkins file is created properly
• Product configuration is accurate
• Dev branch should build & deploy in Sandbox
• Release branch should build & deploy in Sandbox

Deploying to the Staging Environment

Once an app has deployed successfully in the Sandbox environment, it automatically deploys to the Staging environment. If any issues occur in Staging, OCC may require the app to return to the Sandbox to fix the issues.

The MAP Staging Environment

The Staging environment is a real VA integration environment where developers ensure apps are able to correctly function in the VA Pre-Production environment. Passing the Sandbox testing threshold automatically triggers deployment to Staging. Developers then test their code on a genuine VA system, ensure compliance through VA Mobile App Conpliance Requirements, and undergo review by the Verification and Validation (V&V) team.

In Staging, developers test their code's functionality and that they comply with VA standards, and then present them to the V&V team. The following workflow illustrates the staging workflow in detail:

Preparing to Deploy to Production

When an app passes V&V, its development team requests permission to deploy to the Production environment. The app development team performs three request activities, described in the following sections which involve drafting a Release Board ticket (TRB) and submitting an NGD (Next Generation Development) ticket.

App Completes V&V

The V&V team reviews all necessary required documentation and a recommendation to OCC leadership. The VA App Verification and Validation ensures that the app’s code is free of bugs and meets its business requirements. 

Once the app passes V&V, the V&V team assigns the artifact ticket to the OCC leadership.

V&V Issues an NGD Ticket

The V&V team issues an NGD ticket and notifies the app project management of the V&V review results. (NGD stands for Next Generation Development, which is a reference to OCC's current generation of software development operations.) The app development PM (Project Manager) references the V&V recommendation to the app sponsor or owner for approval.

Technical Review Board (TRB) Completes Qualitative Review

The Technical Review Board, comprising Connected Care and Office of Information and Technology stakesholders, reviews all NGD production tickets and makes final approvals for apps to move to the The Mobile Application Platform (MAP) Production Environment.

Release Candidate Types

The first release of an app requires working through the entire CI/CD pipeline. Subsequent releases may qualify to work through a reduced pipeline without sacrificing VA quality standards. The development team's project manager decides whether a release candidate is a Major, a Minor, or a Patch release. The requirements and documentation to release a version varies accordingly:

Major Releases (Version X)

A Major release is an app's first release to production, or any subsequent release that has added functionality or architecture changes. (Major Releases of existing products have breaking changes: There are removed or changed features and dependent modules have to modified to be compatible with the new version.) Major Releases must progress through the entire MAP pipeline and submit a complete set of compliance documents during review. OCC decides if apps that do not access VA networks ("informational" apps), are eligible to comply with a reduced set of compliance certifications.

Minor Releases (Version X.Y)

A Minor release is an incremental feature set enhancement. Minor releases may introduce new features but may not change behavior for existing APIs. Minor releases are always backward compatible with their parent Major release. If an app adds a feature, but the module is backwards compatible, it qualifies as a minor release. Minor release candidates resubmit updated credentials for most of the compliance requirements during review.

Patch Releases (Version X.Y.Z)

Only bug fixes that impact no other changes to the app qualify as patch releases. Patch release candidates resubmit a subset of updated records during review.

VA App Verification and Validation

Before an app can move from Staging to Production, it must pass a thorough review by the VA Office of Connected Care's Verification and Validation (V&V) team. The app team can submit a V&V Review Request anytime after an app reaches Staging in the VA External Cloud (VAEC). The app team creates the request by filling out a V&V wiki template. After the V&V receives the request from the app team, the V&V team does the following:

1. Complete a thorough documentation review.
2. Arrange for the app team to demonstrate the app's features and capabilities.
3. Provide recommendations to the app's Business Owner.

Based on the V&V team's recommendations, the System Owner determines if the app is ready to move from Staging to Production. 

V&V Intake Documents

Below is the current full set of documentation and compliance artifacts developers submit to V&V for review. Depending on the application, this list may vary if the app does not integrate with external systems. See Getting Started Developing Mobile Apps  for additional details.

Development Project Documents

OCC provides instructions for drafting app development records on the MAP Documentation Guidance wiki page. Development project documents include the following:

• Jira Epic Report
• Jira Project Stories Report
• Technical Debt Report
• CodeRepo release Notes .md file
• Test Execution Log (TEL)
• Defect Log
• System/Service Design Document (SRVDD/SDD)
• Deployment, Installation, Backup, Rollback (DIBR) Guide
• Risk Log

Compliance Documents

OCC provides instructions for creating and submitting compliance review documentation. Compliance documents include the following:

• Last Office of Information Security (OIS) Security Code Review Report (see Data Security)
• HP Fortify Code Scans(See Code Review)
• Section 508 Submission/Validation Statement (See Section 508 Compliance)
• Patient Safety (See Patient Safety)
• Privacy and Security Checklist (See Privacy and Application Data Security)
• HFE Self Certification (See HFE Mobile App Review Process for an overview)
• Branding Self Certification (See VA Mobile Branding Requirements and Resources)
• WASA Questionnaire (See below)

The V&V Team reviews all the required documentation and creates a Review Findings Report (RFR) that provides information on the application or service and whether the supplied information passed or failed the V&V review. V&V creates a Jira ticket for documentation that fails and assigns it to the App team for resolution. V&V emails the RFR to the System Owner and the app development team. Final approval to deploy the app to Production lies with the app owner.

About the WASA& MASA Questionnaire

The Office of Information & Technology (OIT) Network Security Operations Center (NSOC) frequently conducts Web Application Security Assessment (WASA) scans of all VA internet content. The WASA provides an in-depth penetration test for common vulnerabilities, such as SQL Injection, Authorization Bypass and Cross-Site Scripting (XSS).

About IAM: Identity and Access Management shared services

VA apps may utilize two Identity and Access Management network services (IAM) to simplify accessing the apps. The two service types are:

• Single Sign-on Authentication services, which simplify accessing the apps.
  • Single Sign-on External (SSOe) provides authentication services for Veterans.
  • Single Sign-on Internal (SSOi) provides authentication services for Staff.
• Access via the Master Veteran Index (MVI) to retrieve identifiers for a Veterans known to the VA by other identity systems VA recognizes, like: ICN, EDIPI, or VistA DFN.

If an app utilizes these services, the development team must submit requests before the app moves to Production.

The Mobile Application Platform (MAP) Production Environment

Preparing your Application for National Release

Once your applicaiton has been approved by MAP leadership and passed the V&V process, an app moves into production for end-user testing and national release activities. Once the application is in the production environment, the application is tested by the field to ensure everything is working properly by the end-users.

Once fully tested an app is then marketed across the Department of Veteran Affairs and can be made available on tthe VA Mobile App store for download and use.

Field Testing Processes

OCC apps typically undergo a phase called Field Testing, which includes processes and support activities that ensure OCC delivers the best possible product. OCC's Field Testing team states:

Field testing strives to continuously improve product quality through data collection and analysis. OCC's Field Testing team uses evidence-based methods to test and develop products for implementation across the VA enterprise. Field testing provides the data gathering and analysis required in order to successfully carry out the implementation of a product.

The field testing process consists of several steps that conclude with an assessment of lessons learned. Lessons learned are identified and reviewed to optimize processes going forward and share valuable insight from the field with other product development teams. Field testing is a bridge between app development and the implementation/rollout of the product. It is separate from usability testing or User Acceptance Testing (UAT). Field testing seeks to find out how well a product will fit in a real-world environment. Its objective is to determine how well a product fits (or does not fit) into existing workflows, assess potential changes that need to be made prior to a broader deployment, and anticipate the value/impact to VA. The data gathered from these activities serves to provide guidance for future app functionality, and the implementation and rollout strategy.

National Release Activities

Once an application completes field testing and resolves any potential bugs found, the application is ready for National Release and can be made readily available through any or all of the options below:

• VA Mobile Application Store
• VA Google Play Store
• VA Apple Store
• VA App Catalogue
• VA Staff LaunchPad
• VA Veteran LaunchPad
• Patient Video Tablets
• Digital Prescription Pad

Once the application is available on the applicable platforms listed above, the application should be marketed by the application team as laid out in the implementation strategy and made available for the use of our VA Veterans or VA Providers.