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 should install the following technical stack:

• Git
• Docker Desktop

How to Kickstart a New Project

Developers once onboarded will have access to starter projects maintained by our Shared Services team to help with service and application development.

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 Starter Kits, obtain accounts to the Sandbox Active Directory, they then deploy their containers to the VA Enterprise Cloud Mobile Application Program (VAEC-MAP) Sandbox. MAP Sandbox is an ephemeral environment where development namespaces can be deleted and recreated as needed. 

The Sandbox is similar to the staging and production environments 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). As a best practice for the required System/Service Design Document (SRVDD/SDD), teams should have their approved System/Service Design Document (SRVDD/SDD) before their application/service can deploy to staging.

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 applications 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)
• Jenkins build pipeline to build, test, and deploy applications.
• Static code quality and security scanning.

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

To move to the Staging environment or SQA environment, the development team submits requests to have the build pipeline and any additional configurations set up. Once ready, the development team may proceed with the automated build and deployment of their application in the SQA 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. Once the code is deployed to Staging, developers then test their code on a genuine VA system, ensure compliance through VA Mobile App Compliance 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.

Preparing to Deploy to Production

The Application/Service Teams submit their application/service request for V&V review in parallel to submitting their requests for permission to deploy to the Production environment. The Application/Service Teams performs two request activities, described in the following sections which involve drafting a Technical Review Board ticket (TRB) and submitting an NGD (Next Generation Deployment) ticket.

Application/Service Teams Issues an NGD Ticket

The Application/Service Teams V&V team issues an NGD ticket, which is a reference to OCC's current generation of software development operations, to the Technical Review Board (TRB) for review.

Technical Review Board (TRB) Completes Qualitative Review

The Technical Review Board (TRB), comprising Connected Care and Office of Information and Technology stakeholders, reviews all NGD production tickets and makes final approvals for apps to move to 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 application'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 applications that do not access VA networks ("informational" applications), 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 application 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, technical debt, flexline findings, OIS findings, and/or minor improvements that impact no other changes to the application qualify as patch releases.

VA Verification and Validation

The Verification and Validation (V&V) Team performs a comprehensive and thorough review of documentation and testing of the applications/services capabilities for the Department of Veteran Affairs/VA Office of Connected Care (OCC). The VA OCC Application/Service Teams are required to submit their application/service release requests through the V&V Automation by utilizing the Jenkins YAML process that creates a JIRA Mobile Application Software Quality Assurance (MASQA) ticket and Markdown Report and notifies the V&V Team that the application/service is ready for review. The V&V Team receives the JIRA MASQA ticket and reviews the “Release Types” (Major, Minor, or Patch) to determine what documentation is required to be reviewed and what testing is required. Verification & Validation (V&V) - Process (VA Staff Only).

The V&V Team reviews all the required documentation and creates a Review Findings Report (RFR) that provides information on the application/service and whether the supplied information passed or failed the V&V review. V&V creates a JIRA MASQA ticket for documentation that fails and assigns it to the Application/Service Team for resolution.

About IAM: Identity and Access Management shared services

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

• Single Sign-on Authentication services, which simplify accessing the apps.
  • Single Sign-on External (SSOe) provides authentication services for external users (currently Veterans, third party vendor support coming soon).
  • Single Sign-on Internal (SSOi) provides authentication services for Staff.
• Access via the Master Veteran Index (MVI) to retrieve identifiers for Veterans known to the VA by other identity systems VA recognizes, like: Login.gov and ID.me.

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

The Mobile Application Platform (MAP) Production Environment

Preparing your Application for National Release

Once your application has been approved by MAP leadership, an application 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 application is then marketed across the Department of Veteran Affairs and can be made available on the 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
• 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.