Getting Started
Guides
Using Humanitec
What happens if you hit "Deploy"?
Understand in detail how an Internal Developer Platform works and what happens under the hood when you hit "Deploy".
Introduction
The Deploy button is one of the most prominent and important buttons in an Internal Developer Platform. Clicking it will create or update a specific environment of your application. This section walks you through what is happening under the hood when pressing this button.
What you've set up before hitting deploy
You or your DevOps team connected your Internal Developer Platform to your tools and infrastructure (see Infrastructure Orchestration for all the details). This typically includes:
- Your Kubernetes clusters are connected. So are your CI pipelines and all required external resources such as databases, DNS, or file storage.
- Specific Environment Types have been defined (e.g., development, QA) that define which infrastructure is provisioned or used once you hit the Deploy button.
.png?alt=media&token=a72bc408-d798-4855-b7c3-30e6dd005674)
Organization settings overview
Also, your application is fully configured (see App Configuration Management for all the details). This typically includes:
- All workloads required for your application have been defined.
- Each workload is configured. This includes things like:
- The specific image to be used is defined.
- All required environment variables are defined (maybe including placeholders for environment-specific environment variables such as specific database connections).
- All required external resources (such as databases) are defined.
- Your DevOps team defined the baseline template to be used when creating the deployment manifests.
What's happening once you hit "Deploy"
Let's assume you set up a simple application like this:
- Two workloads: one frontend application and one backend service with the following configuration:
- Frontend application: exposed via public URL.
- Backend service: a PostgreSQL database.
- An environment called Development of type development.
Your application draft (it's a draft since it has not yet been deployed) now looks like this in Humanitec:
If you hit Deploy, the following things are happening:
- 1.Your Internal Developer Platform checks the environment type to be used (development in our example from above).
- 2.From that, it checks which specific resources to use for the new deployment (e.g., which Kubernetes cluster to deploy to, which database server to use).
- 3.Let's assume your environment has never been deployed before...
- 1.Your Internal Developer Platform creates a new namespace within the Kubernetes cluster for the new environment.
- 2.It creates a new PostgreSQL database for the backend service.
- 3.It creates a new subdomain to be used to access your frontend application.
- 4.Your Internal Developer Platform then takes the non-environment-specific configuration for both workloads, adds in the environment-specific configuration (e.g., the specific database and URL to be used), and applies them to the baseline configuration.
- 5.From that, it creates all the required manifests needed to deploy the new environment. These Manifests can be exported.
- 6.In a final step, your Internal Developer Platform will use the manifests to run the deployment and record all deployment logs.
- 7.If defined, your Internal Developer Platform will trigger a webhook once the deployment is finished (e.g., to trigger an automated test run).
Each deployment in Humanitec is stored in a so-called Deployment Set. This way you have a log of all deployments ever tun through your Internal Developer Platform. You can use these logs to recreate the specific deployment later on or to diff it against any other deployment to see the non-environment-specific differences.
​
Last modified 1mo ago