I've been around a long time in the Umbraco dev community, one of the struggles in the early years was having a decent dtap flow
Umbraco is a db driven asp.net project. Some things are stored on filesystem like js/css/templates but others are in the db. Also in v2-7.x everything in the db only had a unique integer id. Once you then had multiple environments and you do some further development these id's won't match...
Live gets new content, dev gets new doctypes... so the id of these new doctypes wouldn't be the same accross environments. Often deploying stuff between environments also consisted of doing manual changes to keep everything in sync...so not exactly an easy/automated process. And also not possible to put all bits in sourcecontrol...
Courier
Enter Umbraco Courier at some point HQ released Courier, a commercial addon that allows you to transfer changes between environments...this even allowed revisions/dependencies checking... but as you know Umbraco is highly customizable and you can add new sections/prop editors/data types... and those can work with content/media/other ids in a nested structure... So to make everything sync at the push of a button is a super complex thing...Courier worked good with pretty standard setups but it had/has it pains...
uSync
Enter uSync since Courier wasn't cutting it for all cases a community member released uSync. This serializes the db stuff to disk (so you can have it in sourcecontrol) and can import those disk items back into Umbraco/db on out of sync environment... I'm not sure about all the details it had initialy but I don't think it was able to serialize everything...but these days it does... even content...
Cloud
Enter Cloud of course running umbraco is more then just source control so HQ released Cloud, which allows you to spin up a new Umbraco instance in a couple of minutes ... add different environments and sync between these. Also has auto upgrades, sourcecontrol of course and other features like Baselines... so it is more then just hosting...At that time the pricing model was also simpel...pay per env.. no limits on bandwidth/nodes/storage/domains
Initial finding
When I first started exploring Cloud it looked great, for a client that wanted a decent dtap I tested the different options at that time (4-5 years ago) and made the recommendation to go on cloud with a big multisite project.
Dtap
THe development of the project was going ok.... the developers used the grid with doctype grid editor... so far so good. The initial sites then whent live ... and a new env was added to do further dev.
Of course since there wasn't a recommended approach for building the backend, grid and doctype grid editor was in place so id's of items could be nested pretty deep (in json stored in the db).
Unfortunately during these early Cloud months that caused a lot of pain...deploys would fail, site would go down... pushing that deploy button was always a super stressy moment. And if it was down you would need to contact support to get it back...Combined with some cloud outages the decision was made to move the site to Azure... currenlty those have been running smoothly on azure with USync combo... Also there wasn't a really good way of keeping a main repo (out of cloud) in sync and pushing from a CI way to cloud.
Further attemps
In the following years I did a couple of other deploys to Cloud, since then the platform matured and 1 item that got added was the uid (so instead of having a different int id accross envs, items now had a single unique umbraco uid that was equal on all). This worked ok in a single developer setup...but of course sticking with Vanilla Umbraco as much as possible, since adding third party bits in some cases also needs extra work to make it work with Deploy/Cloud... + the main repo was also the Cloud one.
Again some cloud outages and bugs that got in due to auto upgrades was not making it a 100% smooth operation. Combined with the new limits on pageviews/content nodes/domain names/bandwidth/storage... the azure move was done again. Since that scales (from a price point of view) in a more fluent way then a sudden increase from 40$ to 210$ a month.
Recent evaluation
In the past months I also checked the state of Cloud. It isn't a secret that in the past month 4 big outages happened that had an effect on all sites.. you can check the history on https://status.umbraco.io/. And the post on the official blog.
Also there are posts that cover how to prepare for cloud outages that are still valid today...
One of the plans was to use baselines in order to setup different sites. But it appears that this isn't as fluent as I imagined it would be. With multiple devs a lot of collision errors happen: https://our.umbraco.com/documentation/Umbraco-Cloud/Troubleshooting/Deployments/Structure-Error/ there is even a video series on youtube describing on how to handle this. As you see this needs powertools (kudu and powershell) so the complexity that is supposed to hide is still needed...Also if you need support in getting these fixed you need to have the correct plan...
Also there is no way to do feature branches, have these on staging for a client to test and then deploy the ones you wish to live... it's all or nothing... So if you need to deploy a hotfix... you can't go trough staging to deploy to live since that would deploy everything... some details on that here on the forum
Verdict
If you are a solo dev and the client has budget to spend on Cloud (doesn't worry about the price increase) it can make sense if you don't want to setup your own env on azure or similar. If the Cloud platform becomes stable that is.
If you are a team of devs, have a bit of devops knowledge, want more control and have gitflow or similar approach. Use Azure devops and add uSync in the mix. No need for the extra layer...
Also be aware that currently Umbraco Cloud is run on VMs... Like seen in the last outages if something goes wrong this can/will affect a lot of sites.
Wishlist
What I would like to see is an Umbraco Devops... that you can just fit in your existing flow to get a decent DTAP. Imagine you signup to a new umbraco.io project, you just point it to your existing repo/branch...(from github for example), then you setup the build with optional tests... could be that cloud has default tests for core/heavily used packages... you could also write/record your own. Once the build and tests are succesfull you can setup where you want to deploy the site. To Azure, a vm, a dedicated server, ftp,...Then Deploy could be used to restore data between backends... (pulling live content to dev to continue dev on a new feature)
Of course this is all based on my experiences with the platform over the past years...feel free to share your thoughts or tips on how to get it smooth...
Top comments (5)
DevOps for Umbraco is a tricky problem, as you rightly point out the database is a bottleneck.
I did have a crack at solving this in the v7 days with Chauffeur (aaronpowell.github.io/Chauffeur/) but having not done anything with Umbraco for a few years I never go around to completing the v8 implementation.
yeah but have you checked deploy? That allows to transfor content (all or selections) between envs... and uSync complete also has that option... so not that a big of a problem I think
Thanks for the write up, Tim, this is valuable to me being a one-man-Umbraco-Cloud site owner. I have contemplated migrating away from UC, no rush, but it might happen in the next year.
no worries, I also did some research on an alternative setup if you want baselines + auto upgrades + content flow: dev.to/timgeyssens/setting-up-an-u...
Our setup is github actions, usync, powerscript adlib and host anywhere :-)
I
Love
Control
:-)