From 3fe445f1849493315f2a25ab2b3678569b5c3634 Mon Sep 17 00:00:00 2001 From: sofietoft Date: Fri, 4 Apr 2025 17:50:53 +0200 Subject: [PATCH 1/8] Update Cloud landing page --- umbraco-cloud/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/umbraco-cloud/README.md b/umbraco-cloud/README.md index 393258cc5c7..2b3e2faab9c 100644 --- a/umbraco-cloud/README.md +++ b/umbraco-cloud/README.md @@ -34,7 +34,7 @@ The easiest way to start with an Umbraco Cloud project is to take a [14-day free Since everything is already set up for you, it is recommended that you get to know your project before you start building. -To start working with and building your site, you can either work directly in the backoffice on the Cloud environment or [clone down the project to your local machine](set-up/working-locally.md). +You can either work directly in the backoffice on the Cloud environment or [clone down the project to your local machine](set-up/working-locally.md). ### Umbraco Cloud Portal Project From e9399d0e2abe2e2912ff6792c5b6efee153567eb Mon Sep 17 00:00:00 2001 From: sofietoft Date: Fri, 4 Apr 2025 19:26:30 +0200 Subject: [PATCH 2/8] Update multiple articles incl deploying deletions --- umbraco-cloud/databases/README.md | 2 +- umbraco-cloud/databases/backups.md | 11 ++-- umbraco-cloud/deployment/cloud-to-cloud.md | 18 ++--- .../deployment/deploying-deletions.md | 65 +++++++++---------- 4 files changed, 44 insertions(+), 52 deletions(-) diff --git a/umbraco-cloud/databases/README.md b/umbraco-cloud/databases/README.md index 5ce0ce24d77..cb381965ff4 100644 --- a/umbraco-cloud/databases/README.md +++ b/umbraco-cloud/databases/README.md @@ -1,7 +1,7 @@ # Working with databases {% hint style="info" %} -The databases on your Umbraco Cloud environments are specific to their environment. This means that no matter what you have configured in the `connectionstring` in your `web.config` or `appSettings.json` file, we overwrite the connectionstring to use the SQL Azure Server we provide. +The databases on your Umbraco Cloud environments are specific to their environment. This means that the connectionstring to use the SQL Azure Server is overwritten no matter what else is configured. {% endhint %} When working with Umbraco Cloud, the way you work with databases might differ from what you're used to. One important aspect of Umbraco Cloud is that you always work isolated to avoid interfering with colleagues or a running website. This includes the database as well. diff --git a/umbraco-cloud/databases/backups.md b/umbraco-cloud/databases/backups.md index d67848e3fd6..7379290dfc9 100644 --- a/umbraco-cloud/databases/backups.md +++ b/umbraco-cloud/databases/backups.md @@ -79,9 +79,6 @@ Once you have uploaded a backup, you might want to restore it to one of your env
Choose which environment to restore the backup on

Choose which environment to restore the backup on

- - - 3. **Optional:** Create a Cloud Backup of the selected environment's database before restoring the backup. 4. Click **"Restore backup"** @@ -93,10 +90,10 @@ Make sure to check your environment and see if everything works as expected and Use the following steps: -* Connect to your SQL Server using SQL Server Management Studio (SSMS). -* Expand "Databases", right-click "Databases", then select "Import Data-tier Application...". -* Proceed through the dialog, by browsing to the saved location of your `bacpac` file, and then setting the options appropriate to your configuration -* Complete the import dialog and the database will be restored. +1. Connect to your SQL Server using SQL Server Management Studio (SSMS). +2. Expand "Databases", right-click "Databases", then select "Import Data-tier Application...". +3. Proceed through the dialog, by browsing to the saved location of your `bacpac` file, and then setting the options appropriate to your configuration +4. Complete the import dialog and the database will be restored. {% hint style="info" %} If a `bacpac` restore fails in SQL server, ensure the 'Contained Database Authentication' flag is set to true for resolution. diff --git a/umbraco-cloud/deployment/cloud-to-cloud.md b/umbraco-cloud/deployment/cloud-to-cloud.md index 5d5d41b519b..332dc74cf13 100644 --- a/umbraco-cloud/deployment/cloud-to-cloud.md +++ b/umbraco-cloud/deployment/cloud-to-cloud.md @@ -4,34 +4,34 @@ updatedLinks: true # Deploying between environments -When your are Working in your Development environment, changes made through the Backoffice are automatically detected and committed to the site's Git repository. This includes Umbraco-specific items like Document types and templates. +When your are working in your Cloud environment, changes made through the Backoffice are automatically detected and committed to the site's Git repository. This includes Umbraco-specific items like Document types and templates. These changes are also referred to as metadata. -Changes made on your Cloud environments will show up in the Umbraco Cloud portal. You'll be able to see what files have been added/changed and who made the changes. +Changes made on your Cloud environments will show up in the Umbraco Cloud portal. You'll can see what files have been added/changed and who made the changes. -To deploy metadata changes from one Cloud environment to another, click the **'Deploy changes to ..'** button on the environment where the changes have been made. +To deploy metadata changes from one Cloud environment to another, click the **Deploy changes** button on the environment where the changes have been made.
-The deployment initiates, and you can see the process in the **Overview of your project.** +The deployment initiates, and you can follow the process in the **Overview of your project.**
Deployment in progress

Deployment in progress

-Once it's done, the changes will be deployed to the next Cloud environment. If you have more Cloud environments, follow the same procedure to deploy the changes up to your Live site. +Once it's done, the changes will be deployed to the next Cloud environment in the deployment flow. If you have more Cloud environments, follow the same procedure to deploy the changes through each environment. ## Important Notes -When you deploy, for example, from your Development environment to your Live environment, changes are made to the Live environment. These changes will then be merged back into the Development environment. +When you deploy, for example, from your left-most mainline environment to your Live environment, changes are made to the Live environment. These changes will then be merged back into the left-most mainline environment. -Here are the automatic steps Umbraco Cloud goes through when you hit the _"Deploy changes to .."_ button: +Here are the automatic steps Umbraco Cloud goes through when you hit the _"Deploy changes"_ button: * Before pushing your changes from the source environment, the engine running Umbraco Cloud - **Umbraco Deploy** - looks for changes in the repository on the target environment * If changes are found, Umbraco Deploy _merges_ the changes from the target environment into the repository on the source environment. * After the merge, the changes from the source environment are pushed to the repository on the target environment. * Finally, the changes pushed to the target repository are extracted to the site, and you will now see your changes reflected in the Backoffice and on the Frontend. -If you have more than one Umbraco Cloud environment, we strongly recommend that you **only make changes to metadata on the Development environment**. Making changes directly on your Staging and/or Live environments can cause merge conflicts when you deploy from your Development environment. +We strongly recommend that you **only make changes to metadata on the left-most mainline environment or a flexible environment**. Making changes directly on other mainline environments can cause merge conflicts when you deploy. -{% hint style="danger" %} +{% hint style="warning" %} It is important to be aware of how deletions work between environments. Some deletions are environment-specific and others are not. For more information see the [Deploying Deletions article](deploying-deletions.md). {% endhint %} diff --git a/umbraco-cloud/deployment/deploying-deletions.md b/umbraco-cloud/deployment/deploying-deletions.md index 8c58b8f2717..277c15367c3 100644 --- a/umbraco-cloud/deployment/deploying-deletions.md +++ b/umbraco-cloud/deployment/deploying-deletions.md @@ -10,28 +10,36 @@ The databases are environment specific. During deployment across environments, U The workflow described above does not recognize deletions of content and schema from the database. You'll need to delete the content and/or schema on all your environments to fully complete the deletion. -The main reason we do not delete schema and content on deployments is that it could lead to an unrecoverable loss of data. Imagine you delete a Document Type in your Development environment. Then, push this deletion to your Live environment, where many content nodes depend on the deleted Document Type. When the deployments go through, all those content nodes would be instantly removed. There is no option to roll back because the Document Type they rely on no longer exists. To prevent such situations, manual deletion is necessary. You must actively decide on each environment for the process to occur. +The main reason we do not delete schema and content on deployments is that it could lead to an unrecoverable loss of data. + +Here's an example of what could happen when a Document Type is deleted and deployed: + +* You've deleted a Document Type in your left-most mainline environment. +* Then, you push this deletion to your Live environment, where many content nodes depend on the deleted Document Type. +* When the deployment go through, all those content nodes would be instantly removed. + +In the scenario explained above, there is no option to roll back because the Document Type they rely on no longer exists. To prevent such situations, manual deletion is necessary. You must actively decide on each environment for the process to occur. Below is the same scenario explained in more detail. ## Example scenario -Let's say you've deleted a Document Type on your Development environment. Now, you want to deploy this deletion to the Live environment, along with some other changes you've made. +The following example will build in the scenario outlined above, calling the left-most mainline environment the **Development** environment. In addition to the deletion, you also want to deploy some other changes you've made. Before you deploy the changes, the Development environment will show that the following changes are ready to be deployed:

Changes ready for deployment

-Following the **Activity log** in the browser, you'll notice the UDA file for the Document Type gets deleted. Additionally, other files with changes are copied to the new environment. +Following the **Activity log** in the browser, you'll notice that the `.uda` file for the Document Type gets deleted. Additionally, other files with changes are copied to the Live environment. -Once the deployment is completed, you will notice the following: +Once the deployment is completed, the following changes has taken place: -* The template is correctly updated -* The Document Type you deleted on Development is still present in the backoffice on the Live environment +* The template is correctly updated. +* The Document Type you deleted on the Development environment is still present in the backoffice on the Live environment. -You might wonder why the Document Type that you have deleted, is still there. The reason is, that we only delete the associated UDA file and not the actual Document Type in the database. +The reason for the Document Type to still be there is, that the associated `.uda` file is deleted. The Document Type still exists in the database. -To delete the Document Type from your entire project, you need to delete it from the backoffice of the other environments. When the Document Type has been deleted from the Backoffice of all the environments and no UDA file exists, you can consider it gone. +To delete the Document Type from your entire project, you need to delete it from the backoffice of the other environments. When the Document Type has been deleted from the backoffice of all the environments and no `.uda` file exist, it is fully removed. -You should keep in mind that if you save your Document Type during the process, a UDA file is regenerated. This can recreate your deleted Document Type when deploying changes between environments. +If you save your Document Type during the process, a new `.uda` file is generated. This can recreate your deleted Document Type when deploying changes between environments. ## Which deletions are deployed? @@ -41,30 +49,21 @@ Here's an overview of what happens when you deploy deletions to the next environ ### Deleting Schema (Document Types, Datatypes, etc.) -Deleted: - -* The associated `.UDA` file - -Not deleted: - -* The entry in the database -* The item will still be visible in the backoffice +| Deleted | Not Deleted | +| --------------------------- | ------------------------------------------------ | +| The associated `.uda` file. | The entry in the database. | +| | The item will still be visible in the backoffice.| ### Deleting a Template -Deleted: - -* The associated `.UDA` file -* The associated `.cshtml` file (the view file) - -Not deleted: - -* The entry in the database -* The template file will be empty, but still be visible in the backoffice +| Deleted | Not Deleted | +| -------------------------------------------- | ----------------------------------------------------------------------- | +| The associated `.uda` file. | The entry in the database. | +| The associated `.cshtml` file (the view file)| The template file will be empty, but still be visible in the backoffice.| ### Deleting Files (CSS files, config files, etc.) -As these are **only** files, everything will be deleted in the next environment upon deployment. +All files are deleted in the next environment upon deployment. ### Deleting Content and/or Media @@ -72,13 +71,9 @@ Deletions of content and media won't be detected during deployments. You must ma ### Deleting Backoffice Languages -Deleted: - -* The associated `.UDA` file - -Not deleted: - -* The entry in the database -* The language will still be visible in the Backoffice/Content dashboard (for multilingual content) +| Deleted | Not Deleted | +| -------------------------- | ------------------------------------------------------------------------------------------------- | +| The associated `.uda` file.| The entry in the database. | +| | The language will still be visible in the Backoffice/Content dashboard (for multilingual content).| Deleting the language in the backoffice on the target environment will ensure the environments are in sync. From 7dd1ec8b6f39766e8a67ed5ca5d28c67a6fdb0d2 Mon Sep 17 00:00:00 2001 From: sofietoft Date: Fri, 4 Apr 2025 19:31:18 +0200 Subject: [PATCH 3/8] Deployment webhook --- umbraco-cloud/deployment/deployment-webhook.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/umbraco-cloud/deployment/deployment-webhook.md b/umbraco-cloud/deployment/deployment-webhook.md index 6827a72019c..997a25e9cd7 100644 --- a/umbraco-cloud/deployment/deployment-webhook.md +++ b/umbraco-cloud/deployment/deployment-webhook.md @@ -1,19 +1,16 @@ ---- ---- - # Deployment Webhook -You can now configure a deployment webhook to be triggered upon successful deployments to any of your Umbraco Cloud environments. For example, when deploying from your local environment to your Cloud Development environment. Upon successful deployment, general information about the deployment will be posted in a JSON format to the specific URL you have configured. +You can now configure a deployment webhook to be triggered upon successful deployments to any of your Umbraco Cloud environments. For example, when deploying from your local environment to one of your Cloud environments. Upon successful deployment, general information about the deployment will be posted in a JSON format to the specific URL you have configured. ## Use cases -There are many use cases for deployment webhooks such as providing a detailed audit trail. Here are some scenarios where Webhooks could be useful: +There are many use cases for deployment webhooks such as providing a detailed audit trail. Here are some scenarios where webhooks could be useful: -1. Any deployments to the Live site could be relevant for many parties in a company. Posting information about a deployment in internal communication channels like _Slack_ is made possible using this feature. -2. Monitoring of the whole deployment cycle. A successful deployment might cause an error to show on the website! Integrating the webhook with other monitoring services, you could find out which deployment caused the issue. +1. Any deployments to the Live site could be relevant for many parties in a company. Posting information about a deployment in internal communication channels like Slack is made possible using this feature. +2. Monitoring of the whole deployment cycle. A successful deployment might cause an error to show on the website. Integrating the webhook with other monitoring services, you could find out which deployment caused the issue. 3. Letting content editors know about particular deployments such as when a new Document Type was added. Will inform them that they can now use the new Document Type. -## Configuration steps +## How to set up a webhook ![Adding deployment webhook](images/Post-deployment-webhooks.gif) From e7510bdcb804014de7340f37f5f645f019044433 Mon Sep 17 00:00:00 2001 From: sofietoft Date: Fri, 4 Apr 2025 19:33:37 +0200 Subject: [PATCH 4/8] Local to cloud --- umbraco-cloud/deployment/local-to-cloud.md | 32 +++++++++++----------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/umbraco-cloud/deployment/local-to-cloud.md b/umbraco-cloud/deployment/local-to-cloud.md index 33921108ae3..7e7d176df68 100644 --- a/umbraco-cloud/deployment/local-to-cloud.md +++ b/umbraco-cloud/deployment/local-to-cloud.md @@ -10,28 +10,28 @@ In this article, you can learn more about deploying your code changes and metada Local changes in your Umbraco Cloud project are automatically detected and synced with your Git client for seamless collaboration. -There are two ways this can be done. You can push the changes using a Git GUI or your terminal. This guide will show how you can use both ways to deploy your local changes to Umbraco Cloud. +There are two ways this can be done. You can push the changes using a Git UI or your terminal. This guide will show how you can use both ways to deploy your local changes to Umbraco Cloud. ## Prerequisites * A clone of your Cloud project. -* A [Git GUI](https://git-scm.com/downloads/guis) or a Terminal. +* A [Git UI](https://git-scm.com/downloads/guis) or a Terminal. * Created some Document Types and Data Types with corresponding `.uda` files. * The files are located in the `/umbraco/Deploy/Revision` folder. -## Deploying using a Git GUI +## Deploying using a Git UI -Once you have created some Documents and Data types, follow the steps below to deploy your local changes using a Git GUI. The guide will use [Fork](https://git-fork.com/) as the Git GUI, however you can use your own preferred Git GUI. +Once you have created some Documents and Data types, follow the steps below to deploy your local changes using a Git UI. The guide will use [Fork](https://git-fork.com/) as the Git UI, however you can use your own preferred Git UI. -1. Go to your Git GUI. -2. Check for local changes in your GUI. +1. Go to your Git UI. +2. Check for local changes in your UI. -
Local changes in Git GUI.

Local changes in Git GUI.

+
Local changes in Git GUI.

Local changes in Git UI.

3. Prepare changes, so they are ready to be committed. - 1. Write a commit subject - 2. Write a description of the commit. - 3. Commit the files. + 1. Write a commit subject + 2. Write a description of the commit. + 3. Commit the files.
@@ -39,7 +39,7 @@ Once you have created some Documents and Data types, follow the steps below to d
-4. Push the files to your cloud project in the GUI. +4. Push the files to your cloud project in the UI.
Push changes to Umbraco Cloud.

Push changes to Umbraco Cloud.

@@ -52,15 +52,15 @@ After deploying changes locally to your Cloud environment, use the Umbraco Cloud To deploy your local changes from local to Umbraco Cloud using a terminal follow the steps below: 1. Navigate to your local projects folder using the `cd YourProjectName` command in the terminal. -2. Check for pending changes in your project with `git status` -3. Add the pending changes with `git add -` -4. Commit the staged files using `git commit -m "Adding updated schema changes"` +2. Check for pending changes in your project with `git status`. +3. Add the pending changes with `git add -`. +4. Commit the staged files using `git commit -m "Adding updated schema changes"`. 5. Push the changes to Umbraco Cloud using `git push`. 1. Do a `git pull` if the push is rejected. -If you have to pull down, make sure to see if any of these commits contain changes to the schema (anything in `umbraco/Deploy/Revision/`). +If you have to pull down, make sure to see if any of these commits contain changes to the schema (anything in `umbraco/Deploy/Revision/`). -To validate your local site and ensure compatibility with the updated schema, use the [**Deploy Dashboard**](https://docs.umbraco.com/umbraco-cloud/deployments/deploy-dashboard) in the **Settings** section of the Umbraco backoffice. +To validate your local site and ensure compatibility with the updated schema, use the [**Deploy Dashboard**](https://docs.umbraco.com/umbraco-cloud/deployments/deploy-dashboard) in the **Settings** section of the Umbraco backoffice. Here, you can see the status of ongoing or completed deployment processes. The status will show whether an operation has been triggered and is in progress has been completed, or has failed. From 22caf11b589a78c4a5d139b0e8e7de071a8828aa Mon Sep 17 00:00:00 2001 From: sofietoft Date: Fri, 4 Apr 2025 19:35:07 +0200 Subject: [PATCH 5/8] Forms on cloud --- umbraco-cloud/deployment/umbraco-forms-on-cloud.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/umbraco-cloud/deployment/umbraco-forms-on-cloud.md b/umbraco-cloud/deployment/umbraco-forms-on-cloud.md index 9b3fd68b159..baa9184389c 100644 --- a/umbraco-cloud/deployment/umbraco-forms-on-cloud.md +++ b/umbraco-cloud/deployment/umbraco-forms-on-cloud.md @@ -32,7 +32,7 @@ Umbraco Forms is part of the [auto-upgrades on Umbraco Cloud](../product-upgrade To avoid having the auto-upgrades overwrite any of your custom settings, we strongly encourage that you use [config transforms](../set-up/config-transforms.md) when you need custom configuration. Additionally, use [Themes](https://docs.umbraco.com/umbraco-forms/developer/themes) when you need to customize your forms. -Whenever a new minor version of Umbraco Forms is ready, eg. 10.x or 11.x, you will get the option to apply the upgrade to your project. When your project is eligible to receive the new version, you will see an "_Upgrade available!_" label on your Development environment. +Whenever a new minor version of Umbraco Forms is ready, eg. 10.x or 11.x, you will get the option to apply the upgrade to your project. When your project is eligible to receive the new version, you will see an "_Upgrade available!_" label on your left-most environment. ### Version-specific changes @@ -54,7 +54,7 @@ To switch to persisting all definitions for Umbraco Forms data in the Umbraco da 1. Make sure all environments are upgraded to **at least Umbraco Forms version 8.5.2 and Deploy 3.5.0**. 2. Make sure your Forms are in sync between all your Cloud environments. -3. Clone down your Development environment. +3. Clone down your left-most environment. 4. Restore content and Forms to the local clone. 5. Open the configuration file `App_Plugins\UmbracoForms\UmbracoForms.config` from your local clone. 6. Add the following key in the `` section and make sure the value is set to `True`: @@ -94,7 +94,7 @@ You will need to follow the steps below to persist Umbraco Forms data in the Umb ``` 3. Remove all existing `data\revision\forms-form__*.uda` files, so it's not possible to accidentally revert to this state (removing `UDA` files won't remove the actual form on deploy). 4. Push the change back to the Cloud environment. - * If you have more than 1 Cloud environment, make sure to deploy the change through to all of them. + * If you have more than one Cloud environment, make sure to deploy the change through to all of them. 5. You are now able to queue your Forms for transfer between the Cloud environments, like content and media. If you do not have the `transferFormsAsContent` setting in the `UmbracoDeploy.settings.config` file, you do not need to make any further changes. From e30bc65343375fd2e3dd46154e297794b40a53ac Mon Sep 17 00:00:00 2001 From: sofietoft Date: Fri, 4 Apr 2025 19:39:17 +0200 Subject: [PATCH 6/8] Fix acronym --- umbraco-cloud/deployment/local-to-cloud.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/umbraco-cloud/deployment/local-to-cloud.md b/umbraco-cloud/deployment/local-to-cloud.md index 7e7d176df68..6a06ec875c7 100644 --- a/umbraco-cloud/deployment/local-to-cloud.md +++ b/umbraco-cloud/deployment/local-to-cloud.md @@ -26,7 +26,7 @@ Once you have created some Documents and Data types, follow the steps below to d 1. Go to your Git UI. 2. Check for local changes in your UI. -
Local changes in Git GUI.

Local changes in Git UI.

+
Local changes in Git UI.

Local changes in Git UI.

3. Prepare changes, so they are ready to be committed. 1. Write a commit subject From 6c2d1e81cfa6a0f522433a5ab157f6517fc2b1f6 Mon Sep 17 00:00:00 2001 From: sofietoft Date: Mon, 7 Apr 2025 10:10:31 +0200 Subject: [PATCH 7/8] Apply suggestions from code review Co-authored-by: Esha Noronha <82437098+eshanrnh@users.noreply.github.com> --- umbraco-cloud/deployment/cloud-to-cloud.md | 2 +- umbraco-cloud/deployment/deploying-deletions.md | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/umbraco-cloud/deployment/cloud-to-cloud.md b/umbraco-cloud/deployment/cloud-to-cloud.md index 332dc74cf13..953df30fcd1 100644 --- a/umbraco-cloud/deployment/cloud-to-cloud.md +++ b/umbraco-cloud/deployment/cloud-to-cloud.md @@ -29,7 +29,7 @@ Here are the automatic steps Umbraco Cloud goes through when you hit the _"Deplo * After the merge, the changes from the source environment are pushed to the repository on the target environment. * Finally, the changes pushed to the target repository are extracted to the site, and you will now see your changes reflected in the Backoffice and on the Frontend. -We strongly recommend that you **only make changes to metadata on the left-most mainline environment or a flexible environment**. Making changes directly on other mainline environments can cause merge conflicts when you deploy. +It is recommended that you **only make changes to metadata on the left-most mainline environment or a flexible environment**. Making changes directly on other mainline environments can cause merge conflicts when you deploy. {% hint style="warning" %} It is important to be aware of how deletions work between environments. Some deletions are environment-specific and others are not. For more information see the [Deploying Deletions article](deploying-deletions.md). diff --git a/umbraco-cloud/deployment/deploying-deletions.md b/umbraco-cloud/deployment/deploying-deletions.md index 277c15367c3..6a68533daa8 100644 --- a/umbraco-cloud/deployment/deploying-deletions.md +++ b/umbraco-cloud/deployment/deploying-deletions.md @@ -10,19 +10,19 @@ The databases are environment specific. During deployment across environments, U The workflow described above does not recognize deletions of content and schema from the database. You'll need to delete the content and/or schema on all your environments to fully complete the deletion. -The main reason we do not delete schema and content on deployments is that it could lead to an unrecoverable loss of data. +The main reason not to delete schema and content on deployments is that it could lead to an unrecoverable loss of data. -Here's an example of what could happen when a Document Type is deleted and deployed: +Here's an example of what can happen when a Document Type is deleted and deployed: -* You've deleted a Document Type in your left-most mainline environment. -* Then, you push this deletion to your Live environment, where many content nodes depend on the deleted Document Type. -* When the deployment go through, all those content nodes would be instantly removed. +* A Document Type is deleted in the left-most mainline environment. +* This deletion is then pushed to the Live environment, where several content nodes depend on the deleted Document Type. +* When the deployment is completed, all those content nodes would be instantly removed. -In the scenario explained above, there is no option to roll back because the Document Type they rely on no longer exists. To prevent such situations, manual deletion is necessary. You must actively decide on each environment for the process to occur. Below is the same scenario explained in more detail. +In the scenario described above, there is no option to roll back because the Document Type they rely on no longer exists. To prevent such situations, manual deletion is necessary. You must actively decide on each environment for the process to occur. Below is the same scenario explained in more detail. ## Example scenario -The following example will build in the scenario outlined above, calling the left-most mainline environment the **Development** environment. In addition to the deletion, you also want to deploy some other changes you've made. +The following example will build in the scenario outlined above, calling the left-most mainline environment the **Development** environment. In addition to the deletion, additional changes that have been made will also be deployed. Before you deploy the changes, the Development environment will show that the following changes are ready to be deployed: From 292898d775c70b57b31e7898acfa26121a3ddf06 Mon Sep 17 00:00:00 2001 From: sofietoft Date: Mon, 7 Apr 2025 11:49:32 +0200 Subject: [PATCH 8/8] Apply suggestions from code review Co-authored-by: Esha Noronha <82437098+eshanrnh@users.noreply.github.com> --- umbraco-cloud/deployment/deploying-deletions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/umbraco-cloud/deployment/deploying-deletions.md b/umbraco-cloud/deployment/deploying-deletions.md index 6a68533daa8..601174ad841 100644 --- a/umbraco-cloud/deployment/deploying-deletions.md +++ b/umbraco-cloud/deployment/deploying-deletions.md @@ -15,7 +15,7 @@ The main reason not to delete schema and content on deployments is that it could Here's an example of what can happen when a Document Type is deleted and deployed: * A Document Type is deleted in the left-most mainline environment. -* This deletion is then pushed to the Live environment, where several content nodes depend on the deleted Document Type. +* This deletion is then pushed to the Live environment, where many content nodes depend on the deleted Document Type. * When the deployment is completed, all those content nodes would be instantly removed. In the scenario described above, there is no option to roll back because the Document Type they rely on no longer exists. To prevent such situations, manual deletion is necessary. You must actively decide on each environment for the process to occur. Below is the same scenario explained in more detail.