| |
|---|
Implementation of Mock ID | Based on last week’s discussion, the Technoforte team has provided details to Sandbox on how to implement the Mock ID. The Sandbox team mentioned that the documentation provided by Technoforte has been reviewed and there seemed to be no major challenges in implementing the Mock ID solution. They expressed optimism about introducing the initial plan for implementation in the following week.
|
MVP Happy Flow | The Sandbox team is relooking at the MVP happy flow and working on defining the exact set of endpoints, API requirements, and data requirements. The team also discussed the importance of aligning these requirements with the GovStack specifications, including Payments, Consent, and the Registration building blocks, specifically for the happy MDP (Minimum Desirable Product) flow.
|
Pending action items | |
Deployment and configuration challenges | The Sandbox team highlighted some challenges related to deployment and configuration of the MIFOS payment building block implementation. They mentioned issues with the s3 bucket, missing files, container compatibility, and versioning problems. There is also a concern about the Fineract Helm chart being updated without a change in the version number. There is a need for maintaining consistency in versioning to avoid confusion and compatibility issues. The team has requested assistance from the MIFOS (Avik’s) team and expressed the need for clear versioning of containers used by the Helm charts. The Sandbox team is waiting on inputs and guidelines on the MIFOS deployment before proceeding further.
|
Compliance with API test harness | The readiness of the test harness for the MOSIP ID building block was discussed. Although it is not yet complete, the test cases are being reviewed, and compliance is expected soon. They address the question of whether compliance with the test harness is essential for the deployment guidelines
|
Sandbox deployment guidelines | |
Balancing deployment and functional alignment | The importance of aligning the functional aspects of the building blocks, not just their deployment, was highlighted. There is a need to that the right functionality is provided through the BB deployment. This will need more involved support from the BB providers to the Sandbox team. It was mentioned that the Sandbox team could learn from and benefit from more access and assistance from BB providers in the various functional aspects and deployment related issues of the BB implementations.
|
Initial discussion around testing requirements for BB implementations before deploying onto the Sandbox | Vasil from the Gofore Sandbox team highlighted key issues to consider while developing the approach for testing the BB implementations before deploying into Sandbox. These include: Testing Rounds: conducting five rounds of testing to ensure the proper installation and functioning of building blocks. This includes initial testing for correct installation and a second level with a heartbeat test to confirm the functionality of essential services. Collaboration with Building Block Teams: working in cooperation with all the teams that provide building blocks to determine the best approaches for testing their applications. This may involve conducting exception tests, functional tests, and unit tests on the building blocks. API Compliance Testing: involves two stages of testing. The first stage involves testing the compliance of the APIs against the GovStack specification. The second stage focuses on integration testing to ensure that the new version of the building block remains compliant with workflows and business applications built on top of it. Alignment with Providers: aligning with building block providers to understand their procedures and establish requirements and specifications for ensuring compliance. Some deviations may be allowed to accommodate different provider procedures, but the overall goal is to ensure that all building blocks are compliant and that upgrades do not disrupt existing applications. Versioning of Building Blocks: introducing versioning for building blocks to facilitate proper integration and avoid confusion. It is important to maintain consistency between integrated building block version numbers and development version numbers. Traceability and Specification Versioning: ensuring traceability between specification numbers and development versions. Includes adopting existing work on versioning specifications and applying a similar approach to the BB implementations too. Adapting to Specification Upgrades: importance of allowing building blocks time to adapt to specification upgrades. If the specification undergoes incompatible changes, time should be given for building block providers to adjust. However, for synchronous changes that do not affect the current environment, providers should be given time to adapt without disrupting the current state. Provider-Driven Building Block Versioning: one suggestion is that building block versioning should be driven by the individual providers. Each provider can propose a new version of their building block once it has been tested and is ready for deployment. After passing the testing stages, the current version in the production sandbox can be replaced with the new version proposed by the vendor. Avoiding Confusion: aligning the version numbers of building blocks with the production environment will help avoid confusion, as the same version numbers will be used throughout the development and integration process.
|
Discussion for alignment between Payments BB and Registration/ Digital Registries BB | Arnold/ Vijay facilitated a discussion around the need for resolving alignment issues between the Payments BB and Registration/ Digital Registries BB seeking inputs from Ingmar. The key issues discussed are available at: Discussion points - Alignment issues between the Payments BB and Registration/ Digital Registries BB (discussed during the meeting on May 23, 2023) - GovStack - GovStack Wiki (atlassian.net) |
