Lifecycle Coordinator Promotion: Sample Topologies

This section provides a set of complete sample topologies demonstrating various patterns and configurations.

Note: In these examples, Local means that the tenants reside on the same API Platform instance as Lifecycle Coordinator. Remote tenants would be tenants residing on a different API Platform instance than Lifecycle Coordinator, in which case communication between Lifecycle Coordinator and the tenant is via REST.

Promotion User's Guide

API Platform Version: 2018.0.0 and later

Table of Contents

  1. Simple two-environment topology with local tenants
  2. Simple two-environment topology with remote tenants
  3. Three-environment topology with local and remote tenants
  4. Three-tenant topology with Fanout
  5. Conditional topology with environment configuration
  6. Three-tenant topology using Join feature
  7. Two-environment topology with disconnected production environment

Simple two-environment topology with local tenants

In this example, tenant1 has been designated as the authentication tenant, meaning that users logging into the topology library via the Lifecycle Manager console are authenticated for tenant1.

{
  "name":"Topology1",
  "properties":[
    {
      "name":"authentication-tenant-id",
      "value":"tenant1"
    }
  ],
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Default Production Promotion",
          "targetEnvironment":"production"
        }
      ]
    },
    {
      "name":"production",
      "displayName":"Production",
      "tenant":"ProductionTenant"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant",
      "id":"tenant2",
      "credentials":{
        "email":"administrator2@mycompany.com",
        "password":"password"
      }
    }
  ]
}

Back to top

Simple two-environment topology with remote tenants

Notes:

  • Since no tenant has been designated as the authentication tenant, the topology will default to using a local tenant with the id lifecycle_coordinator for Lifecycle Manager console authentication.
  • The tenant definitions include an address property, indicating that they are remote.
{
  "name":"Topology1",
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Default Production Promotion",
          "targetEnvironment":"production",
          "rules":[

          ],
          "properties":[
            {
              "name":"match-policies-by-name",
              "value":"true"
            }
          ]
        }
      ]
    },
    {
      "name":"production",
      "displayName":"Production",
      "tenant":"ProductionTenant"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "address":"http://tenant1:9940",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant",
      "id":"tenant2",
      "address":"http://tenant2:9940",
      "credentials":{
        "email":"administrator2@mycompany.com",
        "password":"password"
      }
    }
  ]
}

Back to top

Three-environment topology with local and remote tenants

Notes:

  • The tenants tenant1 and tenant2 are local; the production tenant (tenant3) is remote.
  • The local tenant tenant1 has been designated as the authentication tenant.
  • The promotion profiles for development to test promotion and test to production promotion indicate that policies, scripts and processes should all match on name when an API is promoted with such dependencies.
{
  "name":"Topology1",
  "properties":[
    {
      "name":"authentication-tenant-id",
      "value":"tenant1"
    }
  ],
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Default Test Promotion",
          "targetEnvironment":"test",
          "properties":[
            {
              "name":"match-policies-by-name",
              "value":"true"
            },
            {
              "name":"match-scripts-by-name",
              "value":"true"
            },
            {
              "name":"match-processes-by-name",
              "value":"true"
            }
          ]
        }
      ]
    },
    {
      "name":"test",
      "displayName":"Test",
      "tenant":"TestTenant",
      "promotionProfiles":[
        {
          "name":"Default Production Promotion",
          "targetEnvironment":"production",
          "properties":[
            {
              "name":"match-policies-by-name",
              "value":"true"
            },
            {
              "name":"match-scripts-by-name",
              "value":"true"
            },
            {
              "name":"match-processes-by-name",
              "value":"true"
            }
          ]
        }
      ]
    },
    {
      "name":"production",
      "displayName":"Production",
      "tenant":"ProductionTenant"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"TestTenant",
      "id":"tenant2",
      "credentials":{
        "email":"administrator2@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant",
      "id":"tenant3",
      "address":"http://tenant3:9940",
      "credentials":{
        "email":"administrator3@mycompany.com",
        "password":"password"
      }
    }
  ]
}

Back to top

Three-tenant topology with Fanout

Notes:

  • Since no tenant has been designated as the authentication tenant, the topology will default to using a local tenant with the id lifecycle_coordinator for Lifecycle Manager console authentication.
  • Tenant1 is local, while the two production tenants (tenant2 and tenant3) are remote.
  • The development environment has two parallel unfiltered promotion-profiles, meaning that assets promoted from the development environment will proceed in parallel to both production1 and production2 environments.
{
  "name":"Topology1",
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Production 1 Promotion",
          "targetEnvironment":"production1"
        },
        {
          "name":"Production 2 Promotion",
          "targetEnvironment":"production2"
        }
      ]
    },
    {
      "name":"production1",
      "displayName":"Production1",
      "tenant":"ProductionTenant1"
    },
    {
      "name":"production2",
      "displayName":"Production2",
      "tenant":"ProductionTenant2"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant1",
      "id":"tenant2",
      "address":"http://tenant2:9940",
      "credentials":{
        "email":"administrator2@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant2",
      "id":"tenant3",
      "address":"http://tenant3:9950",
      "credentials":{
        "email":"administrator3@mycompany.com",
        "password":"password"
      }
    }
  ]
}

Back to top

Conditional topology with environment configuration

Notes:

  • tenant1 has been designated as the authentication tenant, meaning that users logging into the topology library via the Lifecycle Manager console are authenticated for tenant1.
  • All tenants in the topology are local.
  • The topology defines two filters based on the internal classifier. These filters are used on the two promotion-profiles in the development environment, to route the promotion to one of the two production environments based on the value of the internal classifier.
  • Deployment Zone mappings are defined on each of the promotion-profiles, to map from the deployment zone used in development to the correct deployment zone in production. These mappings are different for each of the two promotion-profiles.
  • The development environment defines a configuration to control the configuration of APIs created in the initial environment:
    • The environment configuration defines two distinct apiImplementationProfiles filtered by the internal classifier.
    • The apiImplementationProfiles deploy the API implementations in distinct deployment zones.
    • The DetailedAuditPolicy is applied to internal API implementations as well as a number of settings on the API implementation such as debugModeEnabled.
    • The path property on each apiImplementationProfile uses a parameter replacement approach to set a path for the implementations that incorporate the name of the API as well as an internal/external qualifier.
{
  "name":"Topology1",
  "properties":[
    {
      "name":"authentication-tenant-id",
      "value":"tenant1"
    }
  ],
  "filters":[
    {
      "name":"internal",
      "classifier-criteria":[
        {
          "classifierName":"internal",
          "values":[
            {
              "value":"true"
            }
          ]
        }
      ]
    },
    {
      "name":"external",
      "classifier-criteria":[
        {
          "classifierName":"internal",
          "values":[
            {
              "value":"false"
            }
          ]
        }
      ]
    }
  ],
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Internal Production Promotion",
          "targetEnvironment":"internal-prod",
          "filterNames":[
            "internal"
          ],
          "deploymentZoneConfigurations":[
            {
              "sourceDeploymentZoneName":"Dev1",
              "targetDeploymentZoneNames":[
                "IntProd"
              ]
            }
          ]
        },
        {
          "name":"External Production Promotion",
          "targetEnvironment":"external-prod",
          "filterNames":[
            "external"
          ],
          "deploymentZoneConfigurations":[
            {
              "sourceDeploymentZoneName":"Dev2",
              "targetDeploymentZoneNames":[
                "ExtProd"
              ]
            }
          ]
        }
      ],
      "configuration":{
        "apiImplementationProfiles":[
          {
            "name":"Internal API Profile",
            "type":"Live",
            "filterNames":[
              "internal"
            ],
            "deploymentZones":[
              "Dev1"
            ],
            "allowAnonymousAccess":"false",
            "approvalRequired":"true",
            "debugModeEnabled":"true",
            "virtualServicePolicies":[
              {
                "policyName":"DetailedAuditing"
              }
            ],
            "virtualHost":"InternalHost.com",
            "path":"/{catalog_asset.name_normalized}/internal"
          },
          {
            "name":"External API Profile",
            "type":"Live",
            "filterNames":[
              "external"
            ],
            "deploymentZones":[
              "Dev2"
            ],
            "virtualHost":"ExternalHost.com",
            "path":"/{catalog_asset.name_normalized}/external"
          }
        ]
      }
    },
    {
      "name":"internal-prod",
      "displayName":"Internal Prod",
      "tenant":"ProductionTenant1"
    },
    {
      "name":"external-prod",
      "displayName":"External Prod",
      "tenant":"ProductionTenant2"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant1",
      "id":"tenant2",
      "credentials":{
        "email":"administrator2@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant2",
      "id":"tenant3",
      "credentials":{
        "email":"administrator3@mycompany.com",
        "password":"password"
      }
    }
  ]
}

Back to top

Three-tenant topology using Join feature

Notes:

  • Since no tenant has been designated as the authentication tenant, the topology will default to using a local tenant with the id lifecycle_coordinator for Lifecycle Manager console authentication.
  • All tenants are remote.
  • The topology defines two filters based on the internal classifier. These filters are used on the two promotion-profiles in the development environment to route the promotion either to the test environment in the case of an external asset or directly to the production environment in the case of an internal asset. Since the test environment also has a promotionProfile defined pointing to the production environment, the two routes can be thought of as joining at the production environment.
{
  "name":"Topology1",
  "filters":[
    {
      "name":"internal",
      "classifier-criteria":[
        {
          "classifierName":"internal",
          "values":[
            {
              "value":"true"
            }
          ]
        }
      ]
    },
    {
      "name":"external",
      "classifier-criteria":[
        {
          "classifierName":"internal",
          "values":[
            {
              "value":"false"
            }
          ]
        }
      ]
    }
  ],
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Test Promotion",
          "targetEnvironment":"test",
          "filterNames":[
            "external"
          ]
        },
        {
          "name":"Direct Prod Promotion",
          "targetEnvironment":"production",
          "filterNames":[
            "internal"
          ]
        }
      ]
    },
    {
      "name":"test",
      "displayName":"Test",
      "tenant":"TestTenant",
      "promotionProfiles":[
        {
          "name":"Default Production Promotion",
          "targetEnvironment":"production"
        }
      ]
    },
    {
      "name":"production",
      "displayName":"Production",
      "tenant":"ProductionTenant"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "address":"http://tenant1:9920",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"TestTenant",
      "id":"tenant2",
      "address":"http://tenant2:9940",
      "credentials":{
        "email":"administrator2@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant",
      "id":"tenant3",
      "address":"http://tenant3:9950",
      "credentials":{
        "email":"administrator3@mycompany.com",
        "password":"password"
      }
    }
  ]
}

Back to top

Two-environment topology with disconnected production environment

Notes:

  • Since no tenant has been designated as the authentication tenant, the topology will default to using a local tenant with the id lifecycle_coordinator for Lifecycle Manager console authentication.
  • DevelopmentTenant is a standard connected remote tenant.
  • ProductionTenant is marked as "connected" : "false" indicating that it is disconnected and Lifecycle Coordinator should not attempt to make calls to it. Note that only the name and id of the disconnected tenant is necessary in the tenant definition.
  • Since Lifecycle Coordinator will assume a preserve-keys mode when promoting to the disconnected environment, the production environment is likely a clone of the development environment, so it will be common that the source and target tenants have the same id.
  • Note there is no difference in the environment configuration from a standard topology, the designation of a tenant as disconnected affects only the tenant definition.
  • The promotion to production specifies that policies should be matched by name.
{
  "name":"Topology1",
  "environments":[
    {
      "name":"development",
      "displayName":"Development",
      "tenant":"DevelopmentTenant",
      "promotionProfiles":[
        {
          "name":"Default Production Promotion",
          "targetEnvironment":"production",
          "properties":[
            {
              "name":"match-policies-by-name",
              "value":"true"
            }
          ]
        }
      ]
    },
    {
      "name":"production",
      "displayName":"Production",
      "tenant":"ProductionTenant"
    }
  ],
  "tenants":[
    {
      "name":"DevelopmentTenant",
      "id":"tenant1",
      "address":"http://tenant1:9920",
      "credentials":{
        "email":"administrator1@mycompany.com",
        "password":"password"
      }
    },
    {
      "name":"ProductionTenant",
      "id":"tenant1",
      "connected":"false"
    }
  ]
}

Back to top