Page History

De Coronado, Sherri    

Safran, Tracy

Kuntipuram, Kumar

Sprint Status

Current Sprint -  Sprint 30 31 (May 1226, 2016 – May 25June 08, 2016)

LexEVS 6.4 S13-500 Agile Development - Sprint Status

Mayo team deployed sprint 29 artifacts and determined stories for sprint 31.

We are looking at moving to the next phase for documentation and tier deployment. We have planned 60 days for tier deployment.

We need to discuss the following next steps:

• Loader and tree extension JIRA items and if they need to be implemented for 6.4.
• Determine when to working on 6.5 work.
• Many issues have been de-prioritized to 6.5

Larry agreed that there are some loader issues that need to be worked on for the 6.4 release.

• We will need to go through the existing loader issues to determine which ones need to be completed in 6.4.

We all agreed to move the backlog issues (not including the loader issues) in 6.4 into 6.5.

LEXEVS-957 - Mapping iterators do not work on distributed.

This issue was closed and two new issues were created to better describe the issues (LEXEVS-960, LEXEVS-961)

Larry agreed that LEXEVS-960 and LEXEVS-961 should be looked at in 6.5

NCI DEV deployment updates

• CTS2 1.4.1 (6.3) snapshot deployment progress
• CTS2 1.5.0 (6.4) snapshot deployment

CTS2 6.3 is installed on DEV. This hasn't been tested on DEV yet.

• Cory will create a FINAL tag on CTS2 6.3 (1.4.1) and place the artifact on the NCI SFTP site.
• Cory will also need to update the PTE to use the correct artifact naming.

CTS2 6.4 is deployed on DEV, but has not be configured yet. Mayo will work with Tracy next week to configure sprint 30 artifacts and test.

6.4 DEV Testing updates

• Lexevs API
• Lexevs Remote API

Mayo has some lexevs remote API fixes that will be in the artifacts we create from sprint 30.

Kim will be able to test these fixes next week.

6.4 Deployment strategy

Status#SprintStatus-Sprint31

LexEVS artifacts are built and on the SFTP site.

Scott is focusing on code clean up and Cory is working on LEXEVS-1789.

Kevin is working on the Remote API testing and making it more generic.

The CTS2 6.3 patch has been built and deployed to QA.

Tin requested that it be moved up the tiers via an email to Barry.

LexEVS testing strategy

• Remote API testing

• System level testing

Remote API testing

• Kevin presented an overview on the remote API testing was done in the past and how he suggested we perform tests going forward.
• The lexevs local API tests against made up coding schemes (automobiles and others).  
• The remote API was testing against real coding schemes. However, there is a lot of potential maintenance with this approach.
• Kevin is working on running the remote API against the same made up coding schemes as the local LexEVS API.
• Kevin has this working in his development environment and work is progressing smoothly.
• Kevin suggested that the developer would do the Junit tests and the end user/testers would test against the real coding schemes.
  • Tracy and Larry agreed that this is a good idea.  
  • Larry noted that he would like the ability to run these tests without having to update the tests each release based on coding scheme changes.
• Kevin mentioned that using the local LexEVS tests would provide more coverage of the remote API codebase.
• Kevin agreed that the tests against the real coding schemes still have great value and should still be run at some level.
• At the QA tier, Tracy was suggesting that we run more integration tests that are similar to the current remote API tests against real coding schemes.
• Mayo would work with Toky to get this set up on NCI's CI server.

Craig will set up a meeting to meet with Toky, Tin, and Tracy to give an overview of Kevin's work on Jenkins using Docker with LexEVS.

LexEVS 6.4 Git Tags and Artifact Naming Conventions

We reviewed this wiki document.

Toky suggested having a property file that would have the artifact names. Jenkins could then ingest this file.

Tracy was questioning why the tag and file name changes at each tier level.

• There was a lot of conversation and concern about renaming artifacts as they go from QA to PROD.

Loader issues/tree extension issues

• Prioritization

This was discussed offline in an email.

• Gilberto set the priority of all OWL2 loader issues as high priority (except for LEXEVS-1337, which is medium priority). The “high” priority items are needed to use this loader in production.
• These need to be completed no later than end of FY16.

Mayo's server doesn't have a public URI resolver anymore.

The lexevs CTS2 service requires to connect to a URI resolver in order perform the unit/integration tests. This forces the developers to have a local URI resolver to connect to in order to build.

We were asking if NCI has any interest in hosting a public URI resolver instance.

Larry was asking if there has been an appscan on their URI resolver. We don't recall specifically if there was one and agreed it would be good to have one done on their current instance.

LexEVS External Users

• Updates