Deployment environment management

Development environment deployments

HeartAI development environments are intended to provide newly developed and experimental features. These environments are available primarily for HeartAI administrators and developers to build and assess these new features, although access is also provided for more general end-users that wish to examine these functionalities. These environments may not be fully tested and end-users may experience errors or failure states. Development functionalities that prove successful and rigorous under assessment are typically progressed to testing and production environment deployments.

For HeartAI development environments:

  • Development deployment versions are released with a rapid cadence and often contain newly developed and experimental features. These functionalities may not be fully tested and users may experience error or failure states.
  • Development environments are purposed towards platform development and are primarily accessed by HeartAI administrators and developers. General end-users may access these environments if they wish to trial new features.
  • The environment is designed to support the development of HeartAI with new and emerging features. These features are experimental and are not supported by a service-level agreement.

Production environment deployments

HeartAI production environments are intended to be operationally-ready, often providing enhanced service assurances through enhanced resource allocation and high-availability with multiply distributed replication. These environments are extensively tested before general availability and are released only when services have been rigorously assured.

For HeartAI production environments:

  • Production deployment versions are typically released with a slower cadence than that of development environments, allowing a period of extended testing to occur within development environments to ensure production-level readiness.
  • Production environments are purposed towards operation-ready use and provide a higher-level of resource availability and service assurance.
  • The environment is designed for the end-user experience. This typically includes the maintenance and guarantee of a service-level agreement corresponding to the requirements of the environment.
  • Developer access and operational processes are more restrictive, such that more consistent rigour can be achieved. This creates a separation between development environments that are purposed towards testing and secure experimentation, while production environments have a well-defined and governed operation.

Policy

  1. Overview
    1.1. HeartAI provides several deployment environments with functionalities and assurances varying across these environments on the basis of access and purpose.
    1.2. HeartAI currently supports development and production environments. Development environments are tailored towards the development of new and experimental features. Production environments are purposed towards operationally-ready deployments.
  2. Development environment deployments
    2.1. HeartAI development environment deployments are tailored towards the development of new and experimental features. These environments are primarily accessed by HeartAI administrators and developers for the purpose of developing and extending HeartAI functionalities. General end-users may access these environments if they wish to trial these new features.
    2.2. These environments are typically provided without a service-level agreement. Users may experience error or failure states when interacting with the functionalities of these environments.
  3. Production environment deployments
    3.1. HeartAI production environment deployments are purposed towards operationally-ready services. These environments are primarily intended for end-user access where a high-level of assurance is required.
    3.2. These environments are often provided with a corresponding service-level agreement, providing a level of service assurance and outlining the expected service availability and operational continuity.
    3.3. HeartAI developer access is often restricted with these environments to maintain ongoing rigour.
  4. In relation to the ongoing review of this policy:
    4.1. This policy should be reviewed at least every 6 months. This review should assess the appropriateness of the existing policy, and should propose any modifications or extensions to the policy where needed.
    4.2. Modifications or extensions to this policy should be reviewed and approved by corresponding governing authorities.
    4.3. This policy welcomes suggestions and feedback.
  5. In relation to the governance and compliance of this policy:
    5.1. This policy must be understood and agreed to by HeartAI administrators and developers before the approval of access to HeartAI platform components.
    5.2. Where this policy does not provide a specification to, or conflicts with, a mandated SA Health or SA Government policy, the existing SA Health or SA Government policy will take precedence. HeartAI administrators will resolve policy deficits by approved modification or extension to HeartAI policy.
    5.3. HeartAI administrators are responsible for ensuring that this policy is compliant with SA Health and SA Government policies.