Discover the all-new UI for cloning workloads and shared resources in this article. Learn how to promote changes across environments while retaining control and transparency. Let's jump in!
Promoting changes across different environments is a key part of any software delivery process. That’s a given. But getting it right? Another story. Application and resource configuration needs to be consistent AND free from error. The good news is that with the Humanitec Platform Orchestrator, this can be done with cloning. The tool allows you to clone individual workloads or entire applications between environments. Which then creates a whole load of new possibilities.
Picture the scene. You need to clone a deployment to create a new environment. This allows you to isolate changes, test updates, facilitate parallel developments, and enable easy rollback and recovery. What’s more, cloning is invaluable when moving changes up the environment release train, transitioning changes from development to test, UAT, and ultimately — to production.
Cloning can be used in a number of use cases. But we also get that managing the states of multiple environments and determining which workloads and resources should be promoted (while others remain in place) can be challenging. That's why we’re excited to introduce our new UI for cloning, designed to enhance transparency and control when cloning between environments.
Drumroll, please: Introducing the new cloning UI in style
While we introduced exciting changes to the design, the cloning workflow remains largely unchanged in the UI. To clone a deployment, you can continue relying on the familiar process: Simply select the 'clone to...' button on any active or past deployment of your choice and specify the desired target environment for cloning. Once you've made your selection, the new cloning modal will be presented to you.
Let’s dive right into the changes. The cloning overlay is now organized into three sections for removing, adding, and updating workloads and shared resources:
Remove workloads and shared resources
This section comprises workloads and shared resources that exclusively exist in the target environment. By removing them from the clone, you ensure their exclusion from the target environment once the clone is deployed.
This applies to the 'logging service' workload in the example above. If not removed, it remains untouched in the target environment.
NB: This section also includes shared resources. These can similarly be removed from the target environment if necessary.
Add workloads and shared resources
In this section, you’ll find a list of workloads and shared resources that only exist in the source environment. By adding them here, you ensure that they’re included in the cloning process and will be replicated from the source environment to the target environment upon deployment of the clone.
The above graphic shows an example where the 'sample-app' workload only exists in the source environment (development). The user can decide whether it should be cloned to the target environment (staging) or not.
NB: While the example focuses on workloads, shared resources can now also be included in the cloning process. These are listed in the same section as workloads, and can be added to the clone.
This section shows workloads that exist in both environments and have changes between them. By cloning these workloads, you can update their contents in the target environment to match the source environment. This ensures that any modifications made to the workloads in the source environment are accurately reflected in the target environment.
As per the above graphic showing the 'sample-service', you have the option to clone the workload’s contents from development or keep it in place as in staging.
NB: Workloads without changes between them are not listed in this section.
How to get started
Feel free to explore and experiment with the new feature to understand how it works. And if you have any questions or need help, we’re always here to help you have the best experience.