Skip to main content

Release Management bLink

bLink offers essential Account & Payment Services and Open Wealth APIs through collaborative partnerships with Swiss Fintech Innovation (SFTI) and the OpenWealth Association, respectively. The release management processes for these APIs are highly structured and involve close collaboration between bLink, the partnering communities, and bLink participants. While the specifics of the release process may vary slightly between the two communities, the overall approach remains consistent.

Release Management bLink

Release Cycle Phases​

  1. Raise Changes: Community members propose changes by opening an issue on the respective GitHub repository. Each issue should clearly outline and justify the desired modifications.

  2. Present & Discuss: Proposed changes are presented during regular community meet-ups or gatherings for comprehensive discussion and consideration.

  3. Adapt: Approved changes are implemented via pull requests by the initial requester within the API YAML.

  4. Finalize: Accumulated changes are integrated into the subsequent major-release version of the API. All pull requests are consolidated into the main branch, enabling transparent review of alterations and discussions on GitHub.

  5. Transition: The new major versions are transitioned to bLink for preparation and approval within the bLink community.

  6. Preparation: bLink presents all changes to its dedicated governance board for review. Community members can approve or reject individual changes based on specific reasons. Following this, bLink creates bLink-specific API specifications and deploys them in the testing environment.

  7. Implementation: Participants are encouraged to actively implement and test the new major versions using the bLink simulators, which provide both manual and automated testing features. Service Provider, in particular, should leverage the integrated readiness-check to monitor their implementation progress. This tool is designed to:

    • Track the technical and functional progress of providers.
    • Ensure providers are on schedule and compliant with bLink’s requirements.
    • Minimize risks of last-minute issues by identifying potential problems early.

    By regularly using the readiness-check, participants can align their implementation with standardized API behavior, ensuring a seamless and compliant release process.

    note

    bLink monitors readiness-check usage and may escalate cases of non-compliance or lack of progress to the Business Working Group.

  8. Verification: Participants must ensure correct and robust integration before releasing the new major version into production.

    • Service Provider must successfully complete the readiness-check to verify compliance.
    • Service User will be validated based on their testing activities as recorded in system logs.

  9. Release: The release process is coordinated among participants and targeted for November.

    • Service Provider:
      • Must release the new major version before December.
      • Deploy the API in parallel mode to ensure accessibility for all participants regardless of version.
    • Service User:
      • Can release the new major version in parallel mode, targeting supported API versions listed in the bLink directory.
      • Alternatively, they may wait until all providers have released the new major version.

    Parallel mode support will continue until the end of Q1 of the following year to accommodate unexpected circumstances.

Release Timeline​

The following graph illustrates the process of the release of a new major-version on bLink:

Release Management bLink

Summary​

The bLink release cycle ensures a transparent and collaborative process for introducing API changes. By adhering to these guidelines, all participants can maintain seamless operations while adapting to new major versions. Service Providers must prioritize readiness-checks and timely releases to foster a consistent and standardized API ecosystem.

Differences between the APIs​

While the release management processes for both SFTI and OpenWealth APIs follow a similar structure, there may be nuanced differences in implementation and community interaction, which are highlighted below.

Account & Payment Services​

  • SFTI GitHub Repository
  • Contact to apply for contribution
  • Timeline Production Release: November, in alignment with ordinary release of Swiss Payment Standards

OpenWealth​

Last updated on