| |
|---|
Sandbox Deployment Guidelines: | Jarkko presented the proposed sandbox deployment guidelines for which there was in general agreement and positive feedback. The aim of the guidelines is to be self-sufficient for any DPG (MOSIP or Mifos) to integrate and deploy their product in the sandbox. Further discussion on any pending deployment issues with Mifos and MOSIP.
|
Deployment Status of Mifos and MOSIP into the Sandbox | Clarification sought on pending deployment issues for Mifos and MOSIP. Mifos (Fineract) deployment seems to be fixed, with the team investigating other raised issues. MOSIP mock ID installation and deployment not done yet, however Sandbox team is comfortable with the information provided by the Technoforte team. Sandbox team is preparing the environment for BB providers to test their product's compliance with the sandbox. Discussion on whether to wait for full MOSIP deployment or proceed with mock ID for MVP. Timeline and complexity of the product to determine the need for mock ID or full MOSIP deployment.
|
Sandbox Playground and Documentation: | Sandbox team developed guidelines and a sandbox playground for testing building block implementations. The sandbox environment is a safe, isolated, and non-production environment for simulating government service systems. The deployment should be self-contained and fully deployed inside the sandbox to avoid external effects. Automated deployment using CI/CD pipelines, with basic smoke tests to verify deployment success. Provided examples of pipeline configurations and deployment for reference. Open to feedback and comments from teams implementing the building blocks. Hardware requirements not discussed explicitly, focus on functionality and compatibility with the sandbox environment. Sandbox environment will be provided to deploy MOSIP and Mifos.
|
Sandbox Environment Setup for MOSIP: | The team specifically discussed the need for a sandbox environment with sufficient capabilities and resources to deploy the minimal set of MOSIP components. It was mentioned that the sandbox should provide as much functionality and resources as MOSIP in a full-stack environment, but there was a suggestion that it might be too much and the BB should hence be kept minimal. The team agreed to deploy the minimum set of MOSIP components and not the entire system. They mentioned the need to set up the environment based on the provided documentation and mirror the setup in the sandbox. The team planned to inform the sandbox team when the environment setup is completed, and then discuss the setup of credentials and other necessary configurations.
|
Deployment for USCT Demo and MVP: | The team discussed the timeline for deploying the three deployments required for the USCT Demo and MVP. It was mentioned that the current back-end solution would require at least two sprints (approximately one month) to start integrating all the necessary components. It was acknowledged that additional time may be needed for the readiness of the building blocks and adjustments based on the environment setup. The exact timeline for the integration and UI integration was not provided, but it was stated that the expectation management would be handled.
|
Compliance and Integration Testing: | The team discussed the need for compliance testing with the GovStack APIs and how to ensure the building blocks deployed in the sandbox are compliant. It was mentioned that the building blocks themselves would validate the APIs against the API specifications and conform to the required tests. Integration tests were also mentioned, and it was suggested to run the same tests after the building blocks are integrated in the sandbox as a sanity check. The possibility of reusing the existing test harness to run the tests on the sandbox endpoints instead of the mock endpoints was discussed. It was emphasized that the post-integration testing is a hard requirement and needs to be addressed. The team agreed to further discuss and take action on this topic including the SolDevelo team. @Dominika Bieńkowska (Deactivated)
|
Addressing Technical Issues and Avoiding Postponement: | During the discussion, it was emphasized that the purpose of these Tuesday Alignment meetings is to focus on technical issues and not management-related matters. It is important to address technical issues and not shy away from making decisions, even if it may be uncomfortable. The observation was made that there is a tendency to postpone important technical matters, which could have a significant impact on scalability and hinder progress. The importance of validating assumptions, learning from failures, and adjusting actions accordingly was highlighted as an essential part of the journey. It was emphasized that this meeting serves as a platform to discuss implementation level issues and to prioritize addressing them to avoid short-sightedness in the process. The understanding was that postponing these discussions could lead to challenges in the future.
|
