NIH | National Cancer Institute | NCI Wiki  
Date

Participants

ICDC Team 


Retrospective

Something our team did well is... (smile) 

  • List anything that went well in this sprint including shout out to others that went out of their way to help (add your name after your comment or feel free to keep it anonymous)
  • Really nice job by Toyo to first organize a call and second take the time to help me understand the technical challenges of creating a file manifest that updates dynamically in accordance with our data model yaml file (Kuffel, Gina (NIH/NCI) [C] )
  • Thank you to Phil for working with Mark J. to come up with an intuitive and elegant solution for maintaining data model nodes and props intended to be represented in our file manifests. (Kuffel, Gina (NIH/NCI) [C] 
  • Thanks to Rana, Ambar (NIH/NCI) [C] for helping with backend work. (Miller, Eric (NIH/NCI) [C])
  • Continued/continuous and really solid progress on data onboarding. RNAseq file records now in place for both the COTC 021 and 022 studies (~360 files in total); OSA02 now fully defined on DEV and awaiting files transfer; OSA04 study likewise; UBC03 study also awaiting file transfer. Really appreciate the ongoing efforts of Miller, Eric (NIH/NCI) [C] to get this done ahead of the DB freezes. (Musk, Philip (NIH/NCI) [C])
  • Updating ICDC resources on AWS, especially the tags that NCI manages, databases using AMI. We updated the base image for our EC2 instance (migration away from Centos). We now have a data dump and restore for Neo4J so we can easily backup our data for the lower and upper tiers. (@ngu, charles)
  • Continuous iteration for the "My Files" Cart page. Its always good to cover ground to make improvement in a holistic kind of way in the sense that one change triggers other changes. (Stogsdill, Hannah (NIH/NCI) [C] )

Something that I think we need to improve for next time is... (sad)

  • List anything that we could have done better in this sprint (these comments can be anonymous)
  • I missed a requirement in a ticket (dynamically fetching most up-to-date manifest props data) and moved some tickets to testing despite not being fully ready - need to make sure all requirements are met for tickets and that they're fully tested before moving. (Miller, Eric (NIH/NCI) [C])
  • Need more communication across Bento-based projects. (Stogsdill, Hannah (NIH/NCI) [C] )
  • The instability of the Interop microservice really blocks a lot of other work. We have to find ways to be more careful about not breaking interop (Musk, Philip (NIH/NCI) [C] )
  • I think “instability” is an unfair characterization of interop. I’d argue that if we require changes to properties, property names, configuration or code functionality for a service that is interconnected with (and interdependent upon!) several other services, we need to ensure that any/all connected services are also updated accordingly and in an order that makes sense development-wise. If the app isn’t getting the proper configuration values or queries, it can’t generate response data out of thin air, let alone function properly. (Miller, Eric (NIH/NCI) [C])


Something I learned about during this sprint is...(lightbulb)

  • Great presentation on common data elements that really helped me finally understand how caDSR, NCIT, and cDEs fit together. (Kuffel, Gina (NIH/NCI) [C] )

  • For metadata test loads we have learned that doing them 1 node at a time is a big time saver in the long run. (Musk, Philip (NIH/NCI) [C]

Actions

  • Kuffel, Gina (NIH/NCI) [C] to create at task in order to bundle web fonts with our application.
  • Better catalog/documentation of system changes, ie. a DevOps log
  • Always reschedule standup meetings
  • Be sure to update test cases if and when requirements evolve
  • DevOps leads should sign off on new microservice designs
  • Create an external service to cache data from external APIs (Performance Caching)
  • Mukherjee, Amit (NIH/NCI) [C] to create a DevOps task to implement performance caching and polling/reporting of outages to Slack or email.
  • Demos will only be on QA or Dev (QA being the preferred environment) moving forward.
  • Use GitHub actions to automate things like deployments for the BE, FE