How we work with Umbraco (on premises and remotely) - 2022 update

In this post I'm going to share some information on the way we work with developing websites and web applications with Umbraco CMS. 

Our environments are set up in such a way that working remotely makes almost no difference from working on-premises. This is true even when working with Umbraco Cloud, since a local development environment is still needed (but that's about the only thing needed there since development environments and data and structure sync between environments are provided).

Our general setup:

To develop sites, we need local development environments as well as somewhere to deploy the final result to for clients to check (a dev or staging website).

For our local development machines we use Windows 10 virtual machines (VMs) to which we connect via RDP, even when we are in the office. This helps us access them from everywhere, essentially using the same development environment regardless of location.

We chose to go this way on purpose, so as not to be dependent on our own infrastructure when we work from home. It costs time and money to install dozens of required programs on a laptop or desktop computer which might not be built for that purpose and which is out of direct control and/or may require maintenance or replacement at any time.

This approach has its pros and cons, but if you have a decent Internet connection it's doable. Our development VMs sit on a fat Hyper-V host, have enough memory and processing power and run on nvme SSDs - can't be faster than that. They're also being backed up in various ways, including cloud backup, quite often. For the record, we use Acronis Hyper-V backup for full VM backups, and Syncback SE combined with Crashplan for file-level backup and cloud backup.

The VPN software we use is nothing fancy - at the moment we're using LogMeIn Hamachi. Before you rush to comment that this is primarily used for gaming, let me tell you that it's proved to be super reliable and the process of issuing or deactivating clients is a walk in the park. If there are no special security conserns, it can do its job just fine, but any other VPN will do as well.

The Umbraco-specific stuff:

We deploy our sites (when not using Umbraco Cloud) on Windows Server VMs (one functioning as a Web server and another one with all possible editions of SQL server installed), either via deploy scripts or via Azure Pipelines.

We assign an external (development) subdomain to each site and lock it down wither with a simple username/password or with ip restrictions, accompanied by a very restrictive robots.txt file so that nobody else than our client can see the actual development site (including search engines). 

Our development machines and the development web server VM all use a common database for each website we develop. This is key to our approach, as you'll see below. (Another option would be to use uSync, but we do that when we go from development to live deployments, synchronizing only structure - again, when not using Umbraco Cloud, since all this functionality is built in there).

Clients can even use this test installation to enter actual data on their website, as the database will be deployed to the live site eventually (when creating a site from scratch).

To synchronize media between all our development VMs and the dev server, we either use Azure Blob Storage containers or synchronize locally using Resilio Sync (although we're currently looking for an alternative since it's not longer being supported).

Synchronizing media locally has the downside of having to store media multiple times, but costs for disk storage (even SSD storage) are relatively low and we always care to have more than enough.

In any case, it's better to be able to see what we're developing as it should be looking like, plus we are able to even see new content clients might upload to the dev server (remember, the database is also common between the dev server and local development machines).

Nothing is perfect, of course - using a common database for multiple dev environments and for the client-facing dev site is expected to have some issues from time to time, for example when updating data on an Umbraco site on our local development machine and the dev server's Nucache goes out of sync - but those are tiny issues compared to the benefits.

Other tools:

Since we're talking about connecting remotely, another tool that has proven to be very useful, especially if you have to deal with dozens of RDP (or ftp, or web) connections daily, is Devolutions' Remote Desktop Manager (read more here). It integrates with a ton of password managers and VPN software and can even keep a cloud-based list of connections (with or without passwords!) to be used more efficiently from various machines.

Last but not least, we keep our passwords secure and handy by using password managers - KeePass for really sensitive passwords such as bank accounts, LastPass Teams for all the rest. 

It goes without saying that we use source control! We have switched to Azure DevOps for all our source control, and utilize pipelines to build and release stuff to hosting environments, be it our own development server that can be accessed by clients, other VPSs, or Azure Web Apps.

All our work is coordinated through Teamwork Projects, as I've already mentioned on my earlier post. We also utilize Teamwork Desk, allowing clients to just send us emails which the entire team can see and pick up, controlling their status and having the option to later easily convert them to one or more tasks on Teamwork Projects.

I hope the information above give you some ideas on how to set up your own development environments, as well as a starting point to comment, criticize (you're welcome to!) and describe your own setups. We don't deem ours a perfect set up - it's just one that helps us do our work better. What's yours?