Skip to content
BETA Try it now Email us
Email us

sales@joomiz.com

Platform teams

Turn your automation into a provisioner within your rules

Put a script, a pipeline or a cloud API behind the provisioner contract. The catalog entry of the type lists every setting a team may write. Feature teams ask only for what you allow.

Email us Read the docs

With Joomiz

  1. Map a type to a pipeline

    The Azure DevOps pipeline provisioner starts a pipeline you already own, for each category and type you map. The pipeline reports its result in a callback.

    Provisioner settings
    azure:
  devops:
    pipelines:
      - kind: managed-resource
        type: postgres
        pipeline-id: 42

  2. Or answer the contract yourself

    Any service that answers POST /plan, POST /apply and POST /inspect can be a provisioner. It receives one change set for each category and type.

    Body of POST /plan
    {
  "applicationId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "kind": "managed-resource",
  "resourceType": "postgres",
  "changes": [
    {
      "id": "shop-db",
      "environment": "test",
      "action": "created",
      ...
    }
  ]
}

  3. Register it against a closed schema

    Register the provisioner for its category and type. The catalog entry of that type lists the allowed settings and refuses all others.

    Catalog entry of the type kong-gateway
    {
  "spec": {
    "type": "object",
    "title": "kong-gateway",
    "required": [
      "control-plane-name"
    ],
    "properties": { ... },
    "additionalProperties": false
  },
  ...
}

  4. See a request refused

    A setting outside the schema fails joomiz validate with a message that names the setting. Valid requests then go through plan and apply.

    $ joomiz validate
          shop-db (postgres):
        spec: property 'size' is not defined in the schema ...

What you get

  • Existing automation that feature teams use through one file and the Joomiz CLI.
  • Requests checked against your schema before your automation runs.
  • A plan that previews every change before apply.

The rules that still hold

  • Each category and type has one provisioner. A second claim is refused.
  • The control plane checks outputs against the catalog entry. A value that does not fit fails the change.
  • A password is never an output value. The provisioner reports the https address of the secret.

Read more in the docs

Talk to us

Tell us about your platform and the services your teams ship.

Email us