Create a new Environment

This page is a chapter of the Quickstart learning path. Make sure to progress through the chapters in the order set in the main navigation. To start out, go to Introduction.

Create a staging Environment #

Applications are typically deployed through a cadence of Environments ranging from development to production. Create the next Environment in that cadence by defining a new Environment type named staging first:

humctl create environment-type staging -d "Staging"

Environments in the Platform Orchestrator are classified by Environment Types. You can use Environment Types in matching criteria, e.g. to make a Resource Definition match any staging type Environment regardless of the number of staging Environments your Applications choose to maintain.

If your Organization already has an Environment type staging defined, you will receive a message that it already exists, which is fine.

Then create the actual Application Environment, based on the existing development Environment:

humctl create environment staging --type staging --from development

To have something deployed to this Environment we could now deploy the draft data copied over from the development Deployment in the web UI, or simply use humctl again to deploy the same Score file while specifying the new target Environment:

humctl score deploy --env staging --wait

You can see how a new namespace will be created for this Deployment which now has staging in its name for the Environment component:

export NAMESPACE_STAGING=$(humctl get active-resource \
  /orgs/${HUMANITEC_ORG}/apps/${HUMANITEC_APP}/envs/staging/resources \
  -oyaml \
  | yq -r '.[] | select (.metadata.type == "k8s-namespace") | .status.resource.namespace')

echo $NAMESPACE_STAGING

Verify that the same objects are present in the new namespace:

kubectl get all -n $NAMESPACE_STAGING

If we had another Resource Definition for a different Kubernetes cluster that matched to the Environment type of staging, then we would not only create a differently named namespace but also deploy to a different cluster instead. Orchestration at work!

Note that the Score file did not have to change for deploying into the new staging Environment, nor should it. Score is Environment-agnostic by design.

Recap #

And that concludes this chapter. You have:

• ✅ Defined a new Environment Type
• ✅ Created a new Environment for your Application
• ✅ Deployed your Workload into the new Environment using Score and humctl
• ✅ Verified the result on the Kubernetes end

Your setup now looks like this:

%%{ init: { 'flowchart': { 'curve': 'linear' } } }%%
flowchart LR
  subgraph scoreFile[Score file]
    scoreWorkload(Workload)
  end
  subgraph platformOrchestrator[Platform Orchestrator]
    cloudAccount(Cloud Account)
    resDefCluster(Resource Definition\nCluster)
    subgraph application[Application]
        envDevelopment(Environment\n"development")
        envStaging(Environment\n"staging")
    end
    resDefNamespace(Resource Definition\nNamespace)
  end
  subgraph cloudInfrastructure[Cloud Infrastructure]
    subgraph k8sCluster[Kubernetes Cluster]
      subgraph namespaceDev[Namespace development]
        workloadDev(Workload)
      end
      subgraph namespaceStaging[Namespace staging]
        workloadStaging(Workload)
      end
    end
  end
  scoreFile -->|humctl score deploy| envDevelopment
  scoreFile -->|humctl score deploy| envStaging
  resDefNamespace -.- namespaceDev
  resDefNamespace -.- namespaceStaging
  resDefCluster -.- k8sCluster
  envDevelopment --> namespaceDev
  envStaging --> namespaceStaging

  %% Using the predefined styles
  class envStaging,namespaceStaging highlight
  class application,k8sCluster nested

Continue to add a database resource to your setup.