selfservice.schema.json

{
  "meta:license": [
    "Copyright 2017 Adobe Systems Incorporated. All rights reserved.",
    "This work is licensed under a Creative Commons Attribution 4.0 International (CC BY 4.0) license",
    "you may not use this file except in compliance with the License. You may obtain a copy",
    "of the License at https://creativecommons.org/licenses/by/4.0/"
  ],
  "$schema": "http://json-schema.org/draft-06/schema#",
  "$id": "https://ns.adobe.com/xdm/common/selfservice",
  "title": "Customer Managed Environment",
  "description":
    "A customer managed environment is an environment that allows a system integration or deployer to manage applications. This is also known as self service.",
  "type": "object",
  "definitions": {
    "selfservice": {
      "properties": {
        "xdm:tenant": {
          "name": "Tenant",
          "description":
            "A description of a customer having a agreement to use a specific set of services (see `xdm:service`). A tenant will typically have a URI which can be used to reference the tenant, and should be resolvable by an identity provider.",
          "type": "string",
          "format": "uri"
        },
        "xdm:applicationOwner": {
          "name": "Application Owner",
          "description":
            "An application owner, distinct from a tenant  (`xdm:tenant`), owns an application (see `xdm:application`) and manages its state. The application owner may be a individual user or roll. Typically the application owner will be a member of the tenant, however that is not a requirement.",
          "type": "string",
          "format": "uri"
        },
        "xdm:application": {
          "name": "Application",
          "description":
            "A set of code, content, and data that together implement an experience. Some applications do not allow a system integrator, partner or customer to perform customization. Other applications may allow customization on a per instance basis. These may be applications managed by the system integrator, partner or customer. An application be defined by a URI referencing the definition of the application.",
          "type": "string",
          "format": "uri"
        },
        "xdm:environment": {
          "name": "Environment",
          "description":
            "A tenant (see `xdm:tenant`) may work with 1..n environments where the application (see `xdm:application`) runs. Each environment serves a purpose in the CI/CD chain providing a structure whereby changes  to the application can be rolled out. Typically the owner of the application manages transitions between environments. A system integrator, partner or customer may be the owner of the application especially where the application has  been extended and customized. An environment may have a URI referencing the definition of the environment. ",
          "type": "string",
          "meta:enum": {
            "dev":
              "A development environment for engineering teams to develop and test against prior to releasing to the QE teams.",
            "qe":
              "A deployment provisioned to satisfy the quality engineering process.",
            "stage":
              "A final deployment environment before production. Typically used to perform final testing and give a reference  deployment to the last production deployment.",
            "beta":
              "A production deployment environment used to introduce end-users of the `application` to new features.",
            "prod": "The production deployment environment."
          }
        },
        "xdm:cluster": {
          "name": "Cluster",
          "description":
            "A group of instances deployed within a environment (see `xdm:environment` ) as part of a topology (see `xdm:topology`) that deliver a service  within an application (see `xdm:application`) often using a single source of persistence. A topology may have one or more clusters (see `xdm:cluster`). A service (see `xdm:service`) is typically delivered by a single cluster. Members of the cluster are typically stateless and disposable, meaning they are created and destroyed to maintain a suitable cluster size to deliver the service against the agreed SLA. A cluster will have a URI referencing the definition of the cluster, including parameters defining its scaling behavior.",
          "type": "string",
          "format": "uri"
        },
        "xdm:CICDPipeline": {
          "name": "CI/CD Pipeline",
          "description":
            "A continuous deployment continuous integration pipeline (xdm:CICDPipeline) is used to deploy an application (see `xdm:application`) conforming to a defined topology (see `xdm:topology`) into an environment (see `xdm:environment`). The pipeline runs a standard process that understands the defining of the topology, environment and application. The pipeline is a shared resource used by many applications and tenants (see `xdm:tenant`), although special tenants may have customized pipelines. A pipeline will have a URI which defines the API.",
          "type": "string",
          "format": "uri"
        },
        "xdm:service": {
          "name": "Service",
          "description":
            "An application (see `xdm:application`) consists of one or more services, deployed into a topology (see `xdm:topology`) and implemented as a cluster (see `xdm:cluster`). The service will generally expose an API to consumers however that service may be private to the application. The implementation of a service my be changed without changing the specification of the service. A service will have a URI defining it.",
          "type": "string",
          "format": "uri"
        },
        "xdm:topology": {
          "name": "Topology",
          "description":
            "A topology is a logical group of services (see `xdm:service`) and their implementations that together form an application (see `xdm:application`). The topology may consist of services and service implementations at different layers throughout an application. Some services within a topology may be satisfied by shared components, for instance many applications may share an edge traffic load balancer. A service will have a URI defining it.",
          "type": "string",
          "format": "uri"
        },
        "xdm:codeRepository": {
          "name": "Code Repository",
          "description":
            "A code repository stores the application (see `xdm:application`) code and any definitions for topologies (see `xdm:topology`), services (see `xdm:service`), clusters (see `xdm:cluster`) and environments (see `(see `xdm:environment`). The CI/CD Pipeline (see `xdm:CICDPipeline`) will read the Code repository to perform integration and deploy the application.",
          "type": "string",
          "format": "uri"
        },
        "xdm:provisioning": {
          "name": "Provisioning",
          "description":
            "Provisioning is the operation which sets up everything required to allow a tenant (see `xdm:tenant`) to deploy an application (see `xdm:application`). This includes setting up the Code Repository (see `xdm:codeRepository`), and allocating any resources that the CI/CD pipeline (see `xdm:CICDPipeline`) might require to deploy the application. Provisioning will ensure that any costs or charges are appropriately registered as being related to the tenant so that billing systems can ensure the tenant is billed. Where the infrastructure is dedicated to the tenant, provisioning will ensure that sufficient infrastructure is available when the first deployment (see `xdm:deployment`) is being performed. If the infrastructure is to be provisioned from a pool, provisioning will ensure that the pool is notified of the level of future demand. Provisioning will understand any legal or jurisdictional requirements and constraints that the tenant may have expressed in the contract and ensure that those requirements and constraints are satisfied.",
          "type": "string",
          "format": "uri"
        },
        "xdm:deployment": {
          "name": "Deployment",
          "description":
            "Deployment is the final act of deploying an application (see `xdm:application`) into an environment (see `xdm:environment`) prior to going live in that environment. This should be achieved via an automated process working from specification and configuration stored in the codeRepository (see `xdm:codeRepository`). Some applications may require the installation of packages directly into a service (see `xdm:service`) or API provided by the application. Where this is the case the deployment process must be capable of supporting that style of deployment and must not make the application or any of its parts available to serve requests while the deployment is incomplete. The deployment process should include steps to validate that the deployment was successful. Deployment is not the same as provisioning (see `xdm:provisioning`), which is a pre-requisite for deployment. Typically a deployment will be performed every time changes in the code repository needs to be made available in the environment` Typically the deployment process is implemented by the CICDPipeline (see `xdm:CICDPipeline`).",
          "type": "string",
          "format": "uri"
        },
        "xdm:artifact": {
          "name": "Artifact",
          "description":
            "An artifact is a package forming the implementation of a service (see `xdm:service`). It is is stored in the artifactRepository (see `xdm:artifactRepository`) published to the artifactRepository by the CICDPipeline (see `xdm:CICDPipeline`). An artifact has a version. Once an artifact with a version is published it becomes immutable. A version may be a unique string such as a SHA identifying a commit in a Git repository, or a semantic version number. Which is chosen depends on the preferred versioning mechanism.",
          "type": "string",
          "format": "uri"
        },
        "xdm:artifactRepository": {
          "name": "Artifact Repository",
          "description":
            "An artifact repository stores released binaries including artifacts (see `xdm:artifact`) either from vendors or created by the CICDPipeline (see `xdm:CICDPipeline`). These artifacts are used by the deployment pipeline to deploy an application (see `xdm:application`) into an environment (see `xdm:environment`). The artifactRepository will allow many versions of an artifact to exist and will be organized in a way that will allow artifacts specific to a tenant (see `xdm:tenant`), application, topology (see `xdm:topology`) and environment to be stored. The artifact repository must not be used to store any sensitive data.",
          "type": "string",
          "format": "uri"
        },
        "xdm:selfServiceAPI": {
          "name": "Self Service API",
          "description":
            "The self service API is a well defined API that will, using the model defined in XDM expose to a suitably authorized client a service implementation that allows that client to one or more applications (see `xdm:application`) within a tenant (see `xdm:tenant`). The API must maintain tenant boundaries, as defined and controlled by an identity provider.",
          "type": "string",
          "format": "uri"
        },
        "xdm:selfServiceUI": {
          "name": "Self Service UI",
          "description":
            "A user interface or portal containing all the functionality of the selfServiceAPI (see `xdm:selfServiceAPI`) presented for use by a human in a web browser interface. Typically this UI will use the selfServiceAPI and be implemented as a browser application or SPA.",
          "type": "string",
          "format": "uri"
        },
        "xdm:selfServiceBuild": {
          "name": "Build",
          "description":
            "The process by which the CICDPipeline (see `xdm:CICDPipeline`) creates a artifact (see `xdm:artifact`). How the build is performed and what the build creates depends on the source code stored in the codeRepository , which will also contain instructions to perform the build. In the case of a java artifact, the build would typically be performed by maven or gradle. In the case of a docker image, the build might be performed by make.",
          "type": "string",
          "format": "uri"
        },
        "xdm:runningInstance": {
          "name": "Instance",
          "description":
            "An instance is 1 copy of a service (see `xdm:service`) implementation running within a cluster (see `xdm:cluster`) within a topology (see `xdm:topology`) deployed to an environment (see `xdm:environment`) as an application (see `xdm:application`) for a tenant (see `xdm:tenant`). Where the application is a java application, deployed to a provisioned virtual machine, the instance will be the java process, however where the application has been deployed as part of a container based application the instance will be the running container.",
          "type": "string",
          "format": "uri"
        },
        "xdm:qualityGateState": {
          "name": "Quality Gate",
          "description":
            "The customer CICDPipeline (see `xdm:CICDPipeline`) defines a number of quality gates that will determine the success or fail of the entire process. If any Pass property being false indicates the quality gate has failed.",
          "type": "object",
          "properties": {
            "*Pass": {
              "type": "boolean",
              "name": "*Pass",
              "description":
                "A quality gate test, false means it failed, true means it passed."
            }
          }
        }
      }
    }
  },
  "allOf": [
    {
      "$ref": "#/definitions/selfservice"
    },
    {
      "required": ["id", "xdm:tenant", "xdm:application", "xdm:environment"]
    }
  ],
  "meta:status": "experimental"
}