That leaves me with the following questions/concerns:
Dev - Staging - Live
It is possible to have up to 3 environments.
Our VSTS setup allows us to deploy to a specific environment's Git repository.
Though Umbraco Cloud expects us to trigger cross environment deploys inside the Cloud's dashboards. I've contacted support about this and this process cannot be triggered elsewhere.
I've thinked about pull requesting the different environments Git repos but I worry this wouldn't trigger all the needed processes.
How to handle PRD hotfixes..?
Content
Code can be dependent upon certain content nodes during startup, building pages, ...
Support advised to built in the needed checks to prevent errors, but this could mean potential reboots of the environment are required (so certain code is triggered again), prolonging the deploy downtime.
I would like to be able to include some content inside my deploy.
uSync comes to mind, anyone experience with this on Cloud?
Backups
Support can provide a Powershell script in order to manually create backups. Haven't had the time to try this out yet, but if anyone has, is it reliable to do this without the aid of support?
Data/revision
We have run into quite some issues with this process failing.
Each time requiring manual intervention using the Kudu tools.
Pushing a new deploy with the fix doesn't retrigger the process when it is in a faulty state. Any tips on aiding this process to success?
There is a forthcoming Skrift article that covers using VSTS with Umbraco Cloud that you may find useful (May 2018). In general though, it uses a similar pattern that leverages the deployments handled inside of Cloud once the build has been deployed to the Dev environment.
That said, it sounds like you want to take advantage of some of the Cloud features (auto-upgrades) but not use others (internal deployments). I'd encourage you to re-examine this approach and make sure this is really what you want; i.e., why not use the Cloud internal deployments? If what you do really want is to subvert the internal deployments that shifts some of the responsibility of making sure the environments stay in sync to your process. It is also, I suspect, what is causing you the issues you note in your point #4.
Stating the obvious, you do give up some flexibility when using Cloud in exchange for a well-defined process that works very well - if you stick to the process. If you need to deviate from the process (very much) you might consider using your own configuration via Azure AppServices, but you will give up some of the features of Cloud.
To your point #1 - you can set your deploy endpoint in VSTS to be any of the environments in your Cloud project so you can pull-merge-push your deployments to any environment. That does shift the responsibility of making sure the environments are in sync to your process. It will also compel you to include any auto-upgrades in your deployment and ensure those are correctly merged in. I advocate for leaving this to the Cloud process as it is one of the primary reasons you select Cloud.
To #2 - I would not recommend uSync in conjunction with Deploy in Cloud. Out team uses uSync on non-Cloud sites quite happily, but not with Cloud. If you do need to include content in your schema deployments you will need to include some checks (and possibly a process to auto-create the content dependency) in your deployment. But, as above, I'd encourage you to make sure you understand how Cloud treats deployments (as schema vs. content) and tailor your process to fit the already defined Cloud process. Here's a good overview of the Cloud deploy approach https://our.umbraco.org/documentation/Umbraco-Cloud/Deployment/
To #3 - using the Powershell script to take a backup of the database is simple and easy to plug-in to a backup/archive process. Once you setup the script with your environment specific information you won't need input from support. Even better than an old-skool DB backup routine, is to make sure you include the /data/* folder in your source control as that contains the source of your site's schema then use the Restore feature to sync the content version from your Live site.
To #4 - If you find yourself consistently needing to manually resolve conflicts via the Kudu console + echo > deploy you may want to re-examine your team workflow and identify where the discrepancies are being introduced. Not saying this never happens in a team workflow configuration (it does) but if it's happening frequently it is likely something related to your workflow and not Cloud per se. I recently went thought this process with one of our clients and we were able to identify the places where these sorts of conflicts were introduced. In all cases it was a case of us using our legacy process that worked against the Cloud process - they were easily adjusted.
I hope that helps you evaluate how you might need to make some process adjustments and determine if Cloud is the best platform for this specific arrangement. As always, please post-back here with your finding so we all can further our knowledge.
just to confirm #2 - uSync won't run on Umbraco Cloud - it actively turns itself off it it detects that the site is running on Umbraco Cloud as there would be to many issues if it did.
#1 - if I can I do want to benefit from what is available for deploying internally. What I need is a way to "Deploy to staging" from VSTS & not Umbraco Cloud's dashboard. So if I understand correctly this is handled in that article?
Our goal is to be able to combine & automate all deploys needed for a client in a central spot, not requiring to login into X different systems triggering Y different processes.
#2 - uSync no go on cloud is noted.
Example: defining the startpath for a wildcard route using virtualnodehandler. This happens during startup & deploying this requires: deploy code -> "products"-node transfer -> environment reboot.
#3 - Powershell seems plausible, Restore is nice for non PRD environments.
#4 - there is 1 case I recall & something I remarked on the deploy process:
A) Template with name X gets deployed to DEV.
Template with name X gets deleted locally.
Template with name X gets recreated locally & redeployed to DEV.
Deploy process fails. It does not delete the old template before creating the new.
B) we had an issue with duplicate file for 1 doc type being deployed, so Cloud env data was in faulty state.
I find it weird that a new deploy (push) with the fix inside this folder doesn't trigger that process again. It requires each failure in that folder to be retriggered using Kudu?
Umbraco Cloud Deployment strategy
I'm doing some research on how to automate our deploys towards Umbraco Cloud. Our company uses VSTS to build & release our other projects.
A nice start was the following blog: http://skrift.io/articles/archive/integrating-umbraco-cloud-with-team-development-workflow/
That leaves me with the following questions/concerns:
It is possible to have up to 3 environments. Our VSTS setup allows us to deploy to a specific environment's Git repository. Though Umbraco Cloud expects us to trigger cross environment deploys inside the Cloud's dashboards. I've contacted support about this and this process cannot be triggered elsewhere. I've thinked about pull requesting the different environments Git repos but I worry this wouldn't trigger all the needed processes. How to handle PRD hotfixes..?
Code can be dependent upon certain content nodes during startup, building pages, ... Support advised to built in the needed checks to prevent errors, but this could mean potential reboots of the environment are required (so certain code is triggered again), prolonging the deploy downtime. I would like to be able to include some content inside my deploy. uSync comes to mind, anyone experience with this on Cloud?
Support can provide a Powershell script in order to manually create backups. Haven't had the time to try this out yet, but if anyone has, is it reliable to do this without the aid of support?
We have run into quite some issues with this process failing. Each time requiring manual intervention using the Kudu tools. Pushing a new deploy with the fix doesn't retrigger the process when it is in a faulty state. Any tips on aiding this process to success?
Hi kows -
There is a forthcoming Skrift article that covers using VSTS with Umbraco Cloud that you may find useful (May 2018). In general though, it uses a similar pattern that leverages the deployments handled inside of Cloud once the build has been deployed to the Dev environment.
That said, it sounds like you want to take advantage of some of the Cloud features (auto-upgrades) but not use others (internal deployments). I'd encourage you to re-examine this approach and make sure this is really what you want; i.e., why not use the Cloud internal deployments? If what you do really want is to subvert the internal deployments that shifts some of the responsibility of making sure the environments stay in sync to your process. It is also, I suspect, what is causing you the issues you note in your point #4.
Stating the obvious, you do give up some flexibility when using Cloud in exchange for a well-defined process that works very well - if you stick to the process. If you need to deviate from the process (very much) you might consider using your own configuration via Azure AppServices, but you will give up some of the features of Cloud.
To your point #1 - you can set your deploy endpoint in VSTS to be any of the environments in your Cloud project so you can
pull-merge-pushyour deployments to any environment. That does shift the responsibility of making sure the environments are in sync to your process. It will also compel you to include any auto-upgrades in your deployment and ensure those are correctly merged in. I advocate for leaving this to the Cloud process as it is one of the primary reasons you select Cloud.To #2 - I would not recommend uSync in conjunction with Deploy in Cloud. Out team uses uSync on non-Cloud sites quite happily, but not with Cloud. If you do need to include content in your schema deployments you will need to include some checks (and possibly a process to auto-create the content dependency) in your deployment. But, as above, I'd encourage you to make sure you understand how Cloud treats deployments (as schema vs. content) and tailor your process to fit the already defined Cloud process. Here's a good overview of the Cloud deploy approach https://our.umbraco.org/documentation/Umbraco-Cloud/Deployment/
To #3 - using the Powershell script to take a backup of the database is simple and easy to plug-in to a backup/archive process. Once you setup the script with your environment specific information you won't need input from support. Even better than an old-skool DB backup routine, is to make sure you include the
/data/*folder in your source control as that contains the source of your site's schema then use the Restore feature to sync the content version from your Live site.To #4 - If you find yourself consistently needing to manually resolve conflicts via the Kudu console +
echo > deployyou may want to re-examine your team workflow and identify where the discrepancies are being introduced. Not saying this never happens in a team workflow configuration (it does) but if it's happening frequently it is likely something related to your workflow and not Cloud per se. I recently went thought this process with one of our clients and we were able to identify the places where these sorts of conflicts were introduced. In all cases it was a case of us using our legacy process that worked against the Cloud process - they were easily adjusted.I hope that helps you evaluate how you might need to make some process adjustments and determine if Cloud is the best platform for this specific arrangement. As always, please post-back here with your finding so we all can further our knowledge.
-Paul
Hi
just to confirm #2 - uSync won't run on Umbraco Cloud - it actively turns itself off it it detects that the site is running on Umbraco Cloud as there would be to many issues if it did.
K
@paul thanks for the extended feedback already!
looking forward to that Skrift article.
#1 - if I can I do want to benefit from what is available for deploying internally. What I need is a way to "Deploy to staging" from VSTS & not Umbraco Cloud's dashboard. So if I understand correctly this is handled in that article?
Our goal is to be able to combine & automate all deploys needed for a client in a central spot, not requiring to login into X different systems triggering Y different processes.
#2 - uSync no go on cloud is noted. Example: defining the startpath for a wildcard route using virtualnodehandler. This happens during startup & deploying this requires: deploy code -> "products"-node transfer -> environment reboot.
#3 - Powershell seems plausible, Restore is nice for non PRD environments.
#4 - there is 1 case I recall & something I remarked on the deploy process:
A) Template with name X gets deployed to DEV. Template with name X gets deleted locally. Template with name X gets recreated locally & redeployed to DEV. Deploy process fails. It does not delete the old template before creating the new.
B) we had an issue with duplicate file for 1 doc type being deployed, so Cloud env data was in faulty state. I find it weird that a new deploy (push) with the fix inside this folder doesn't trigger that process again. It requires each failure in that folder to be retriggered using Kudu?
is working on a reply...