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 selfservice.",
  "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 resovable 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 customisation. Other applications may allow customisation 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 integratior, partner or customer may be the owner of the application expecially where the application has  been extended and customised. 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 statisfy 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 refencing the definition of the cluster, including parameters defining its scaling behaviour.",
          "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 pipleline runs a standard process that understands the definingion 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 customised pipelines. A pipleline 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 implimentation 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 Repostitory 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 registerd as being related to the tenant so that billing systems can ensure the tenant is billed. Where the infrastrucutre is dedicated to the tenant, provisioning will ensure that sufficient infratructure is available when the first deployment (see `xdm:deployment`) is being performed. If the infratructure 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 juristrictional requirements and constraints that the tenant may have expressed in the contract and ensure that those requiremetns 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 enviroment. This should be achieved via an automated process working from specifcation 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 stepts to validate that the depoloyment was sucessfull. Deployment is not the same as provisioning (see `xdm:provisioning`), which is a pre-requisite for deployment. Typically a deployment will be perfomed 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`) publised 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 prefered 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 pipleine 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 organised 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 repsitory must not be used to store any sensitive data.",
          "type": "string",
          "format": "uri"
        },
        "xdm:selfServiceAPI": {
          "name": "Self Service API",
          "description":
            "The Self Serivce API is a well defined API that will, using the model defined in XDM expose to a suitably authorised client a service implemenation 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 potal containg all the functionality of the selfServiceAPI (see `xdm:selfServiceAPI`) presented for use byt a human in a web browsesr interface. Typically this UI will use the selfServiceAPI and be implemented as a browser applicaiton 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"
}