Forem: Thomas Morris

Umbraco Codegarden 2023

Thomas Morris — Tue, 01 Aug 2023 00:00:00 +0000

I wrote an article for TPXimpact about my experience at Umbraco Codegarden 2023.

Recently, a couple of our team had the opportunity to attend the annual Umbraco conference known as Codegarden. Hosted in Odense, Denmark it pulls together 800+ in person to the event, but also a number of people were able to attend online as a hybrid experience.

Read in full here: Umbraco Codegarden 2023

Quick guide: upgrading Umbraco 9 to 10

Thomas Morris — Fri, 04 Nov 2022 16:38:51 +0000

Hey folks, here's a quick guide on how to upgrade Umbraco 9 up to version 10, with some extras around Umbraco Cloud. There's a few gotchas in there, so wanted to share some notes all in one place.

Why

First of all, the biggest reason for upgrading is to align with the Long Term Supported (LTS) version of Umbraco. i.e. if there is a version of Umbraco to upgrade to, then this is the one that's going to get support for a longer period of time.

More details on that here: Umbraco LTS

Outside of that, there are a few new handy updates:

Improved cross-platform support, now using SQLite for development
WebP support for optimised images
User permissions based on languages
Read only mode for properties
Runtime modes
Updated dependencies
Improved performance

How

Umbraco provide a really handy series of steps in their docs.

Check the link for full details, but here's a short summary:

Take some backups!
Update to .NET 6
Update {ProjectName}.csproj to enable implicit usings and nullable reference types:

<PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
</PropertyGroup>

Upgrade package references, the Umbraco HQ packages are now using 10.x.x. Check any other dependencies if you have them added, e.g. Contentment
Update Program.cs with the following:

public class Program
{
    public static void Main(string[] args)
        => CreateHostBuilder(args)
            .Build()
            .Run();

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureUmbracoDefaults()
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStaticWebAssets();
                webBuilder.UseStartup<Startup>();
            });
}

Remove the following files/folders used by Umbraco:

/wwwroot/umbraco
/umbraco/PartialViewMacros
/umbraco/UmbracoBackOffice
/umbraco/UmbracoInstall
/umbraco/UmbracoWebsite
/umbraco/config/lang
/umbraco/config/appsettings-schema.json

Remove the following files/folders used by Umbraco Forms:

/App_Plugins/UmbracoForms
/Views/MacroPartials/InsertUmbracoFormWithTheme.cshtml
/Views/MacroPartials/RenderUmbracoFormScripts.cshtml
/Views/Partials/Forms/

To re-enable the appsettings IntelliSense, update your appsettings.json

"$schema": "./appsettings-schema.json",

Commit your changes and get ready to deploy!

Note, if using Umbraco Cloud, you'll also need to delete the files/folders through KUDU from both the repository and wwwroot folders before pushing the upgrade changes.

References

Umbraco Cloud upgrade notes
Umbraco Forms upgrade notes
Umbraco Deploy upgrade notes

Breaking down Umbraco

Thomas Morris — Tue, 16 Mar 2021 00:00:00 +0000

I wrote an article for TPXimpact about why you might choose Umbraco for a project.

Umbraco’s benefits are many. Using technologies we’re already familiar with, the CMS allows our solutions to achieve a breadth of functionality and remain malleable post production.

Read in full here: Breaking down Umbraco

GitHub Actions: an intro

Thomas Morris — Wed, 19 Aug 2020 00:00:00 +0000

There are quite a few build and deploy options available to developers these days. Previously, I have wrote about using a combination of Team City and Octopus Deploy. These are still good tools, but will likely require a bit of setup and probably require a VM.

A more recent trend is to have your actions linked to your repository, where you can have it all self contained and in one place. There are pros and cons to both, but I'm gonna show you how you might do that with GitHub Actions.

dotnet

I work mostly with .NET, so lets take a look at the workflow for that. With .NET Core you can now use Linux (and macOS) as your build target. Here we're using ubuntu-latest.

We're also setting the relevant DOTNET_VERSION and running our commands, dotnet build and dotnet publish. Problems with the build will be visible within GitHub and you can follow along with the progress.

Finally, we're pushing our published version of the app to Azure Web Apps using a publish profile. You could also choose to generate a NuGet package and push to a feed for distribution.

Note, you can also build .NET Framework apps, that will look a little different but the concept is the same. You'll target windows-latest as that is a prerequisite for .NET Framework, and the commands will be msbuild.

node.js

If you've got a FE repo, then you'll likely want to use npm to compile some assets and package them up. Here's how you can do that.

We've set up our NODE_VERSION and then run the commands, npm install and npm build. At that point, we might want to package up the assets or deploy as an application.

other

There are lots of other options available to you, without going into all of them here, I encourage you to take a look through the docs and see what you might want for your needs.

If you're interested in what's installed on the runners, then take a look at this repo which contains the full list of software and spec for each.

The approach here can also be used for similar tools such as Bitbucket Pipelines or Azure Pipelines. Choose what fits the bill for you.

Have fun!

Building a bottle shop

Thomas Morris — Mon, 10 Aug 2020 00:00:00 +0000

One of the things that is important to an ecommerce experience is the speed at which you can make informed decisions and place items in your cart. From there, the next phase will be to checkout and proceed with the order. Typically, this is classed as a conversion and you want as many as possible. You might do various tests to achieve that end goal and nudge the customer along that path.

What if you were open to the idea of not pushing the customer to checkout immediately and provide them time to make their choices, even over a few weeks. This was a concept that we played with at BeerBods, centred around a reservation of beer, to build a case of beers you pick in your own time. The experience itself is more about exploration and finding the beer you want.

Not only does that shift the UX in a slightly different direction, it also has some technical challenges. Namely, how do you reserve a beer, how is this stock controlled and how do I come back to my continue with my purchase.

Introducing Umbraco

Umbraco as a CMS allows for a lot of variation in terms of document types and property editors. Essentially, you can build a custom editing interface relatively easily to manage your content. In my case, I wanted to add products to Umbraco and have these editable by anyone in the team. There was no data warehouse, so adding directly into Umbraco was ok in this scenario. I was able to define the required information and set up some basic stock control with SKUs and pricing. Since we were already using Umbraco, it was comfortable to use on this front.

The product pages themselves can be rendered using traditional patterns and templates. The more interesting part came when adding the functionality to add a beer to your case.

Enter VueJS and Algolia

VueJS is a javascript framework that allows for building SPA (single page applications) like functionality, introducing more dynamic and responsive user interfaces. It can be added with relative ease to an existing website, which made it a good option for building our 'shop' front. VueJS would be responsible for rendering components, handling FE state and making calls to our API.

Algolia is a search platform that has a number of pre-built components to integrate with it's service. There was one of particular interest that near enough provided the basis for our 'shop' and the required functionality. This included a list of results, options to filter, sort and search. The idea of adding this kind of service had a number of benefits, it was quick to get started and by having an external service handling search powered by a CDN, it was very responsive to customers. We could push data to the service (whenever a product was updated) and query the results wherever we needed.

Combined, we were able to build a UI that was quick to load, easy to filter and visually interesting with a lot of customisation options. All of the API calls would be triggered from the FE and the state would update our UI to present back to the user.

Adding Fluidity

So, we've got our products and our UI for the front end. We now need to persist changes and provide a stateful system for the current user. This was done by implementing custom database tables and an API to enable adding items, removing items and saving these items for a later date.

These custom database tables can be exposed in our Umbraco instance by using a package called Fluidity. It provides a CRUD like experience for the editors so that we can see what's being added and when, as well as allowing us to add beers on the behalf of a customer.

It's important to note that the idea of persistance is 2-fold, once when we are on the FE and we need to ensure state between sessions and also on the BE, where we need to actually store the data and reserve the beer. This distinction means that we don't get people adding multiple beers filling up stock until they commit to saving that data. At which point we've got their details and can follow up if necessary.

When it comes to purchase or if the customer comes back to their choices, we can load these from the API and allow the customer to proceed. The items can be locked in and an order can be made just like any other checkout, allowing the next stage of fulfilment in the warehouse.

If the customer didn't come back (which did happen), then we'd prompt them to finish their case via email. If after the 30 days they hadn't made a purchase, then we would need to remove their reservation and put the beers back into the shop for other customers. This was done by using Hangfire, a tool for running background tasks at desired times.

The result

What we were looking for was a responsive, easy to use 'shop' front for customers to pick beer and save until they were ready to make a purchase. We needed the ability to add beers to our shop and view details about what was in progress or had been ordered. By using a combination of Umbraco on the back end, and VueJS / Algolia on the front end, the result turned out how we wanted it to and we saw great customer interaction.

Note: This functionality is no longer live and BeerBods subsequently joined Beer Hawk, another online beer company.

Enabling features in production

Thomas Morris — Wed, 18 Dec 2019 00:00:00 +0000

When deploying features or new changes to our websites, we might not want them to be available to all users at once. It would be nice if we could slowly introduce new features to our users. We might even want to completely disable them and have them there in secret. In this article, I'm going to present a few different ways in which you can release features into production, even when they might not be fully complete.

Background

Before we look into the ways in which we can get our features into production, it's useful to think about how we might have typically developed new changes in our website before a release.

One of the most common ways is to use feature branches in a gitflow scenario, where you would build your new feature, deploy to a test environment and then try and merge those changes with anything else that has changed in the meantime. You'll probably bundle a number of changes together and then release those to production.

Some of the issues at this stage might be that you've got a tricky merge, you've tested something in isolation and when you bring it all together other issues might arise. You also haven't really trialled those changes with actual users, so those changes may not be desired or there could be problems with how it all works.

Benefits and options

Therefore, it's probably a good idea to highlight some of the benefits as to why you might want to integrate your new changes sooner rather than later.

your features get into production quicker
you can get feedback earlier
you can test things in reduced quantities
you should end up with a better product
your client will be happy

You might have seen reasons like this elsewhere, and that's because they actually run true for agile development and the scrum process, which in turn is a good fit for continuous delivery. A notion that your app is always in a deliverable state, since any new changes have been safely integrated somehow.

On to the ways in which we can enable our changes...

App settings

One of the easiest ways is to define in your web.config, application settings somewhere, or provide settings in your Umbraco solution to features on and off. You'll need to check this setting within your code before including the new changes for your users.

This can be done with a feature helper, which you can query the app setting and then return a true or false as to whether the new changes should be included or not.

public static class FeatureHelper
{
    public static bool IsFeatureEnabled(string featureFlag)
    {
        // check if we have enabled functionality via web.config
        bool.TryParse(ConfigurationManager.AppSettings.Get(featureFlag), out var setting);
        return setting;
    }
}

If you'd like to turn off entire controllers or action methods, one of the ways in which you can do that is via the use of attributes. These will decorate your actions and apply the filter before any of the other code is run. In the attribute logic, it will call our feature helper to determine whether or not a feature should be applied.

public class FeatureAttribute : ActionFilterAttribute
{
    public string ConfigVariable { get; set; }        

    public FeatureAttribute(string configVariable)
    {
        ConfigVariable = configVariable;        
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        // if the feature is not enabled, then redirect to 404
        if (!FeatureHelper.IsFeatureEnabled(ConfigVariable))
        {
            filterContext.HttpContext.Response.Redirect("/404/");
        }
        else
        {
            base.OnActionExecuting(filterContext);
        }
    }
}

This allows for features to be controlled relatively easy in terms of when it is available, but it's an all or nothing solution which might not be desired when you want to tentatively introduce customers to your new feature.

Session

We can apply changes based on a user's session data, which could be enabled via a campaign to help with testing. Ask for people to click a link and become part of the session. You can then trigger an update that will kill off any session data if there are issues. The code above that we used for checking app setting can be amended to apply with session data.

public static class FeatureHelper
{
    public static bool IsFeatureEnabled(string sessionFlag)
    {
        // check if we have a valid session to enable functionality
        var sessionVar = HttpContext.Current?.Session[sessionFlag];
        if (sessionVar == null)
        {
            return false;
        }

        return bool.Parse(sessionVar.ToString());
    }
}

This is great for ad hoc testing, as everything can return to normal after the session. This is ideal if you don't have an account system set up, but it is helpful if you can target or segment your users if you have a hypothesis you want to test.

A/B testing would be a good scenario here. One set of users could get the feature enabled and the other set could continue as normal to see if anything is improved if your feature relates to performance or conversions. It's important that you can define what improvement looks like or can at least get some feedback from your users.

User preference

If you do have an account section, you could provide the user the choice as to whether they want to opt in to a newly released feature that you might want to test further before enabling for all. You would need to check against the current logged in user as to whether or not they would like to see those changes.

In Umbraco, you could define this as a member property or membership group so you can see within the backoffice which users have enabled your feature and segment your users that way. If your changes are more granular, then using properties is probably preferred.

Just to note, for members in Umbraco there is the concept of role based access, which is tied with membership groups, so could be an option if you wanted to hook in that way instead. This uses .NET authorisation under the hood.

This puts the control on to your users, and they are more likely to be actively engaged with a feature and also understand that there may be issues. If they're not happy with how it works, then they can easily opt back out and carry on as normal. Within your website, you can provide an option for feedback based on whether a new feature has been turned on. They can submit reports and you can gain some quality insight as to how your users are actually using your changes.

Deployment slots

If you're doing your deployments via Azure App Services, then another option at your dispense, is to use deployment slots. The main use case for this is to run a staging slot alongside your live slot, and to swap them when doing a deployment to ensure that you've tested your changes, warmed up your site beforehand and traffic is switched over without downtime.

There is another benefit to it though, in that it can allow you to drive traffic to either slot based on a percentage. That way you can test with 20% of users before rolling out to the other 80% and this is managed through deployment. You can do similar with traffic manager or other load balancing rules.

With this option, it's even more important that you can provide suitable metrics and logs to determine how your new changes are performing. Without reasonable guidance, you're in the dark as to whether or not it's a good idea to roll out.

Features as a service

With the rise of microservices, why not make use of a service that can handle our features? One of those services is LaunchDarkly, which provides a dashboard for your features and has a number of libraries (inc. JS and .NET) that you can integrate with. As a solution, it'll allow you to get a full feature management tool pretty quickly, and one that should provide plenty of options albeit at a price. Useful to consider, and there may well be others out there. The concepts should still be the same as we've outlined in this article.

[Update]

Since originally writing this article, another option which I've found is the .NET Feature Management library. This is built on top of the .NET configuration system and provides a nice set of APIs for using in your applications. It looks like a great option. Here's a quick start guide to set up with Azure.

Conclusion

Testing features in production is a big part of continuous improvement and ties in well with the continuous development way of doing things. You can deliver changes quicker and have greater confidence in when a feature is enabled for all. Ideally, you can ramp up usage in a controlled manner.

You can gain feedback on your changes from real users and scenarios, which may in turn provide much greater insight as to how something works. The end goal being that your changes have been well integrated and are of better quality overall.

App offline strategies for your website

Thomas Morris — Tue, 09 Oct 2018 00:00:00 +0000

It's undesirable, but sometimes you'll be in a scenario where you may need to take your sife offline for maintenance. This could be an upgrade to your CMS of choice (e.g. Umbraco), processing of changes behind the scenes or simply restricting users at high traffic.

app_offline.htm

The simplest way to do this is to place an app_offline.htm file in the root directory of the website. This will instruct .NET to route all traffic to that file and show this to the user. It'll need to be simple html and you'll need to inline any CSS that you want applied.

This is great if you want to restrict traffic altogether, but if you want to do stuff in the background then you are a bit stuck.

IIS Rewrite

So, one way in which you can get around that is by using a rewrite rule which negates a certain IP. This will allow whoever visits your site via the IP added, to browse the website without obstruction. Anyone else, will get served the offline file. Below is an example transform that you can use to achieve that.

<rule name="App-offline" stopProcessing="true" enabled="true" xdt:Transform="InsertIfMissing" xdt:Locator="Match(name)">
    <match url="^(.*)$" ignoreCase="false"/>
    <conditions logicalGrouping="MatchAll">
        <add input="{URL}" pattern="/offline.htm$" ignoreCase="false" negate="true"/>
        <add input="{REMOTE_ADDR}" pattern="^127.0.0.1$" ignoreCase="false" negate="true"/>            
    </conditions>
    <action type="Redirect" url="/offline.htm" redirectType="Found"/>
</rule>

Maintenance manager

Perhaps you don't have a specific IP you want to allow and are interested in being able to turn this off and on. Well, the good news is if you are using Umbraco, then Kevin Jump has created a package for that. It's called maintenance mode for Umbraco. You can login to Umbraco and then you'll be given the option to apply the restriction to everyone, as well enabling access for back office users if you wish.

You can download that here: https://our.umbraco.com/packages/backoffice-extensions/maintenance-manager/

Limited downtime?

There's a few ways to achieve this. One of the most common being blue-green deployments where you alternate between active and inactive versions of the website, resulting in one being live and the other being updated and switched to. Usually this will require some kind of load balancer although with deployment slots in Azure you can achieve a similar thing.

You could use tooling such as Octopus Deploy to set up a variety of deployment strategies, with the ability to run custom scripts and actions throughout the deployment. You can also configure a deployment to run at scheduled times (e.g. 2am where there is expected to be little traffic).

Using Models Builder in an Umbraco project

Thomas Morris — Sun, 03 Jun 2018 00:00:00 +0000

A while back I gave an overview of the different options that Models Builder provides you. I didn't go into a lot of detail, but I did cover why you might want to use one option over another.

Structure

Fast forward a little, and I think I've reached an approach that I'm happy with and allows me to build things in a way I want without adding extra complication. I'm more familiar with an MVC type scenario and so here's the kind of solution I normally end up with for Umbraco projects.

Project.Web.Core - class library
Project.Web.UI - website project (reference to the above)

There will likely be some other projects in there as well, e.g. tests.

I would typically place my models within the Core project and then utilise these within the views of the UI project. To do that, there are some configuration options to instruct Models Builder as to how to create models.

<add key="Umbraco.ModelsBuilder.Enable" value="true" />
<add key="Umbraco.ModelsBuilder.ModelsMode" value="AppData" />
<add key="Umbraco.ModelsBuilder.ModelsNamespace" value="Project.Web.Core.Models.Content" />
<add key="Umbraco.ModelsBuilder.ModelsDirectory" value="~/../Project.Web.Core/Models/Content/" />
<add key="Umbraco.ModelsBuilder.AcceptUnsafeModelsDirectory" value="true" />

The above will place the models generated by Models Builder into my Project.Web.Core project, so that I can then use them how I wish. Include them in the project and do a build, and they will be included in the project dll.

The good thing about this is if you already have a project that was using Model.Content.GetPropertyValue("propertyAlias") it's not too difficult to change them over to strongly typed models. Models Builder itself is essentially doing all that for you. If you're starting fresh on a project, then there a few other options for your model/mapping needs. None of the below generate models, so are quite different in usage to Models Builder. They do offer more complex scenarios in terms of mapping and granular view models, and may be something you prefer.

Using the models

I've now got a bunch of files that provide me with the generated models from Umbraco. These are content models and they all inherit from PublishedContentModel. They are partial classes. When it comes to using these models, it might be instantiated via a controller or it might just be there for me via Umbraco's routing.

In a view, this is what we can do:

@inherits UmbracoViewPage<MyModel>

Then, within the view there will be intellisense and I will be notified of compilation errors. A nice benefit of using strongly typed models. Since we made use of UmbracoViewPage we also get access to all the Umbraco helper methods.

Ok, that sounds great. But, there's something a little iffy with using a model that Umbraco generated for me and is closely tied with the content in Umbraco. What if I wanted to extend this or have my own properties? Well, there's a solution for that. The official docs suggest that we create another partial class and add what we need there, but I think I prefer this method. We can just inherit from the model that Models Builder gave us.

public class FridayBeersViewModel : FridayBeers
{ 
  public FridayBeersViewModel(IPublishedContent content) 
    : base(content) { } 

  // custom properties 
  public bool ShowBanner => BannerImage != null;
}

We've still got all the properties from the generated model and we can also build up a custom view model, which more closely matches the output in our views. As a side note, if you're view model ends up with little relation to the generated model then you probably shouldn't be inheriting from it and can just roll your own.

In the controller, you would then have something like this.

public class FridayBeersController : BasePageController
{ 
  public ActionResult FridayBeers() 
  { 
    var model = new FridayBeersViewModel(CurrentPage); 
    // apply any other updates on the model 
    return CurrentTemplate(model); 
  }
}

I'm hijacking the route so that I can amend the default behaviour of Umbraco. I'm also making use of the template based routing in Umbraco, where the template name matches my action. BasePageController just inherits from SurfaceController and IRenderMvcController, and has a method called CurrentTemplate that resolves the template and passes the model to the view. Here's the example in Umbraco core: view on github.

Compositions

The above example would work well for a page or a block of content, but we might want to break things up a little more and make better use of sharing code. When we use compositions, what we get from a generated sense is an interface and then our content models implement those properties. They can also make use of many compositions. This is great, because it means we can then define the interface as the model within a view if we want to. For example, if we had a interface such as IMetaData we can create a related partial that handles the meta tags on our site.

@inherits UmbracoViewPage<IMetaData> 
<meta name="description" content="@Model.MetaDescription" />
// etc.

Or we might have a couple of pages that have a banner, and a few without. We just let our doc types use the compositions and they know how to render the banner.

ModelTypeAlias

I'm sure at one point during development of an Umbraco website you would have created a class with some constants in them, relating to the alias of the doc type. An easy way to vary your code depending on the doc type. Well, Models Builder provides this in a straightforward way.

public partial class ExamplePage : PublishedContentModel
{ 
  public new const string ModelTypeAlias = "ExamplePage"; 
  public new const PublishedItemType ModelItemType = PublishedItemType.Content; 

  public BasePage(IPublishedContent content) 
    : base(content) { } 

  // other properties
}

To use this, just do ExamplePage.ModelTypeAlias when you need it.

Summary

I've outlined a few ways in which you can use Models Builder on a project above perhaps what you get out of the box, so that you can get the most out of it in a simple manner. As a pattern, this should allow for easy extensibility and a quick way of consuming the content from Umbraco.

Upgrading Umbraco

Thomas Morris — Tue, 17 May 2016 00:00:00 +0000

During a recent project, I was tasked with upgrading a site from v4 of Umbraco to the latest and greatest. There are a few reasons for this and it doesn't come without it's challenges, but I think the end result is definitely worth it.

Note: For reference, I am talking mainly around upgrading an existing implementation of Umbraco and not migrating to another instance. Also, specifically around major releases, since patch updates rarely cause any issues and where possible you should always keep up to date if you can.

Why Upgrade?

Well, who wouldn't want to make use of the updated UI and far improved underlying architecture of Umbraco. There are many things which the HQ team (and others within the community) have been working on and a lot can change in a relatively short time in the tech world.

Complete redesign
Works in mobile formats
Better editing experience
New service layer
Better performance
Greater support for latest technology
Packages!
etc.

On the other hand, there may be problems around how the site used to be built (think WebForms/XSLT) which render it difficult to upgrade or simply too time consuming to get back on to the upgrade path and work with the best version of Umbraco. These are choices which are largely down to the client and will require some conversations around. Obviously, we'd all like to work to the latest version and be on a common playground, but sometimes other things hinder us from taking these steps.

The good news is that with some planning and a little bit of perserverance and knowledge it isn't actually as daunting as you think it might be. I've heard many a time that the concept of upgrading a site that was built 3-5 years ago was better off with a complete rewrite and rework of the content, including fresh designs. Whilst this might be the path you go down more often than not, sometimes it's not exactly feasible or best placed to migrate a bunch of content and then factor in all of the changes around that. For larger sites, this certainly becomes the case.

What's the process?

Since 7.3, largely an Umbraco upgrade can be done via NuGet without too much extra work required. This is all dealt with by the migration scripts that were added and are included with each minor release from now on (even dating back to FourOneZero). When you update all the files to the latest version, Umbraco will perform a check against the database and if it finds that it needs to update then you will be prompted to upgrade the database via the installer. Click the button and wait until you see the new Umbraco UI.

But things might not go as smooth as that, sometimes the installer might fallover or it will report that there are incompatible data types. What do you do then? When it comes to the data types, I found that you could map these to the newer counterparts or simply take a note and update those once you have performed the base upgrade. Take a note of what was there before and what you want to have afterwards. As for when it fails, find the error and look for support on the forums, or place an issue on the tracker. Everyone that does this, will help Umbraco to help others and make the process better for all.

At this point I'm referring mostly towards the concept of getting Umbraco working in terms of the back-office and having a working CMS. We still need to take a look at our code that actually runs the website. Above I mentioned that you might be using old technology or you might be using packages / data types that are no longer compatible. The prep work around figuring out this stuff before is important and will provide a decent comparison between where you are and where you want to be. I found that exporting the doc types, templates and macros from the database was a particularly useful exercise for this. It's quite possible that there aren't many custom implementations and that actually once you've done the database side of things, Umbraco works without any major adjustments.

Some of the other things you might want to look into:

update the icons
update data types (if required)
figure out best use of packages
assess the use of doc types (it's possible to change them and sort into folders)
assess the use of macros (could it just be a Razor partial?)
check over the content

Switching out WebForms/XSLT for MVC/Razor can be a time consuming task, but in the end it turns out to be an opportunity to amend some of the methods from before and update to new techniques. It's also a rather nice way of realising that XSLT was rather nasty, and in getting rid of it all you can brief a sigh of relief that another Umbraco site has moved on from the not so distant past. Figuratively speaking of course. Unfortunately, you won't be able to switch out too much when it comes to content structure, but you may be able to upgrade some of those old packages to their equivalent v7 counterparts. For example, Embedded Content now becomes Nested Content and everyone is happy.

Conclusion

So, you've got an old site and are thinking about taking the leap. Assess your options, figure out what is important and how big the scale of the job might be. Take backups and compare. Embrace the changes and enjoy the new world of Umbraco. It's quite a good CMS you know.

Continuous delivery for .NET (revisited)

Thomas Morris — Fri, 03 Jul 2015 00:00:00 +0000

Last year I wrote about deployments and the idea of continuous delivery for .NET. During that article I spoke about how to set up and configure TeamCity and Octopus Deploy as tools for deployment as well as adding some notes around process.

Well, things change and constant improvements are made, so this is a look back on that article and an update as to how the process has been modified. The good news is that the tools chosen in the first article have become staples in the deployment process and what we are talking about here is a refinement. To reiterate the purpose...

TeamCity is the build tool, Octopus Deploy is the deployment tool.

TeamCity

As mentioned before we are using TeamCity to build the solution, perform tests and create an artifact for deployment. We also use a template so this can be shared across projects.

Configure version (GitVersion)
Fetch packages, build solution and run OctoPack
Front end tasks (e.g. npm install / grunt / gulp)
Perform tests and check code coverage
Publish package to Octopus Deploy NuGet server

You may want to split this out into 2 or 3 configurations depending on requirements. Reasons for doing this would be if you wanted to run your unit tests separately (they might take a long time) or if you wanted to publish your artifact as a dependency (i.e. manual task to push the artifact which is created in your other configuration).

GitVersion

We are using this as a meta-runner within TeamCity, there are other options as to how you use this tool such as command line or MSBuild tasks. What this does is create our SemVer or NuGet version automatically for us based on our git history. Previously we were doing a lot of the versioning manually and then we came up with a powershell script to achieve a similar outcome until we stumbled upon this which does it all for us. It follows Gitflow and Github flow conventions and can be applied to other branching strategies with some configuration.

Octopus Deploy

Used to deploy an artifact (NuGet package) to a given environment, as well as setting up a website in IIS and updating variables for different SQL connections. Our process here is largely the same, yet Octopus Deploy has grown up a little since then and now has support for lifecycles, automatic release creation and (in next release) offline deployments amongst some other really useful features.

Test SQL connection
Grab NuGet package
Create / update website in IIS
Deploy files to website folder
Update variables / apply transforms
Test URL (200 OK)
Notify status of deployment via Slack
Clean up / apply retention policies

Steps 2, 3, 4 and 5 can actually be done via one step in Octopus Deploy (deploy a NuGet package), but I have split it out here for better readability. We have also added some basic tests around our deployment...

Test SQL connection : if we can't access the database using the provided connection string, we don't deploy
Test URL : we ensure that we get a 200 OK status back once we have deployed
Notify status : we use Slack for sending out a deployment status (could also send an email if you prefer traditional methods)

Depending on the project or usage case you might want to do other steps such as backup the database or website folder, grant permissions to a certain user, or install a package required for deployment via Chocolatey for example. There are loads of other options in the step template library: https://library.octopusdeploy.com/

Lifecycles

This was introduced in 2.6 and allowed for structuring your deployment process between environments. So, you could set it up to no longer allow a release package to be deployed straight to Production without any testing for example. This forces you to take a release through the proper deployment process and get sign-off before promoting.

So, an example lifecycle could be set up like this...

Internal testing

Dev (auto-deploy)
QA

Client testing (any 1)

UAT
Pre Prod

Go live (any 1)

Production
DR (backup servers)

Within this you can specify whether all of the environments need to be deployed to or at least one in the lifecycle phase, denoted in brackets above. You can also set different retention policies per phase, so you would probably want to keep all releases in the 'go live' phase, but maybe the latest 5 in the 'internal testing' and 'client testing' phase.

3.0

A new version of Octopus Deploy is in pre-release. With this comes a bunch of changes and new features...

Deployment targets which allow for offline deployments, Azure websites, SSH and Linux support
Rebuilt with SQL Server rather than RavenDB
Improved performance
Something called delta compression, which only transfers things that have changed in your package and should make deployments a lot quicker.
Migration tool so you can export your configuration into JSON and import into other instances of Octopus Deploy
Changes to tentacle architecture, which means that the deployment aspect of a tentacle is no longer tightly coupled to the Octopus version. Enter Calamari, a command-line tool invoked by Tentacle during a deployment for doing deployment tasks. It is also open-source, so you can fork and make it your own.

Awesome Umbraco

Thomas Morris — Fri, 01 May 2015 00:00:00 +0000

Many of you are probably aware that one of the great things about Umbraco is the fact that it is easily extendable and can be used for all sorts of flexible solutions. This is mostly down to the community and the people who are constantly building upon a solid foundation.

It would be a shame for all this great work to go unnoticed and so Lee Kelleher has created a repository that showcases some of these packages and groups them into their use.

A collection of awesome Umbraco 7 packages, resources and shiny things.

Next steps

Check out the Github repo and add some packages to the list!

Continuous delivery for .NET (part 1)

Thomas Morris — Thu, 09 Oct 2014 00:00:00 +0000

One very important factor of being a developer is deploying your code to the appropriate environment without anything failing. In order to do this, we should be automating as many tasks as possible to reduce human failure. Of course, some degree of human interaction should happen but by in large, we shouldn't need to do much once we have set up our deployment process.

Simple guide

At it's very basic, this should happen every time we work on a project.

Create project + repo
Write some code
Push some code to repo
Grab code and push to server

Now... parts 1, 2 and 3 will largely be the same wherever, but 4 could be done a number of different ways and there are various different settings / updates required to get a working website. Let's not go into too much details of the different options, but look at a particular method for making this work.

TeamCity and Octopus Deploy

In order to for us to deploy, we are going to use TeamCity and Octopus Deploy. There is a bit of configuration required to do so, but this should be simpler than the traditional Web Deploy method.

It is worth noting that one of the goals in deployment is to allow different roles within the process. So, the devs can push code and then the sysadmins or tech leads can manage deployments. Therefore, publish from Visual Studio is completely out of the question. This has a few advantages in that the relevant people are in charge of their remit. For example, a dev doesn't have the ability to push changes to Production and therefore a degree of protection / sign-off is involved. sysadmins can create a new server and see at a granular level what gets pushed if they choose to. Important server details are not exposed, which can be the case with Web Deploy.

Below is the basic overview of steps required in set up...

Install TeamCity on build server (one time only)
Install Octopus TeamCity plugin (one time only)
Install Octopus Server on build server (one time only)
Create servers for project (one time only for each project)
Install Octopus Tentacle on required servers (one time only for each server)
Install OctoPack in project via NuGet (one time only for each project)

As shown, a lot of these tasks you will not need to revisit and once completed, will allow you to deploy without the need for manual intervention.

TeamCity

Used to build the solution, perform tests and create an artifact for deployment. This will have continuous integration set up for the dev branch so that we don't have to trigger the release each time. We can use a template to share this across projects.

Checkout repository and build solution (run OctoPack)
Perform tests and check code coverage
Publish package to Octopus NuGet server
Create Octopus release (trigger Octopus Deploy)

Octopus Deploy

Used to deploy an artifact to a given environment, as well as setting up a website in IIS and updating variables for different SQL connections. This all happens on the server we are deploying to via a secure connection.

Grab NuGet package
Create website in IIS
Deploy files to website folder
Update variables / apply transforms
Clean up / apply retention policies

When a release is created, Octopus Deploy will keep this indefinitely unless you tell it to. This means that you can rollback quickly to a prior release, but also means that you could be left with a number of files left on the server that you don't want. Therefore, within Octopus Portal you can amend the number of releases you want to keep and for how many days. More info can be found in the documentation.

Why use both?

It is true that you could use TeamCity to deploy to each environment and perform configurations for you. However, this is reliant on Web Deploy being installed on the server you wish to deploy to. This is not a requirement for Octopus Deploy, which uses the idea of tentacles to open up a communication between the build server and the web server. This has several security enhancements and is generally easier to configure. You could also get Octopus Deploy to set up a site in IIS or perform Powershell tasks for you, something TeamCity and other build platforms are not built for.

All in all, it is about using what is built for the task at hand. TeamCity can be used for building the code, running the tests and creating a single release package. Octopus Deploy can then be used to deploy this NuGet package wherever you want and ensure that the configuration is correct for the environment, even cleaning up files in the process.

If you would like to read more, there is a blog post detailing this approach, which explains why Octopus Deploy was created.

Example setup

1 build server with TeamCity and Octopus server installed
1 web/db server for internal Development/QA (shared web and db)
1 web/db server for UAT (could be separate web and db)
1 web/db server for Production (could be separate web and db)

In your project you would need the following transforms...

Web.Development.config
Web.QA.config
Web.UAT.config
Web.Production.config

These will get run automatically when uploaded to the web server by Octopus Deploy. There are a couple of things to take note of, however. Ensure that the transform matches the environment name in Octopus Deploy and make sure that the files are included in the NuGet package. For more notes on this, check the documentation.

Octopus Deploy also has this idea of variables that can be set within the Octopus Portal (admin area). This means that you can define your variables and specify which environment these will apply to. As long as you have these turned on for your project, they will overwrite the name/value pairs within your config files (not just web.config). There is also the added benefit of being able to define variable sets and inherit these on a project. One such example, could be a set of logging options that you only enable for UAT and Production, but you tend to do this on every project. With a variable set, you can ensure they are included with little configuration. See the documentation for more examples.

Forem: Thomas Morris

Umbraco Codegarden 2023

Quick guide: upgrading Umbraco 9 to 10

Why

How

References

Breaking down Umbraco

GitHub Actions: an intro

dotnet

node.js

other

Building a bottle shop

Introducing Umbraco

Enter VueJS and Algolia

Adding Fluidity

The result

Enabling features in production

Background

Benefits and options

App settings

Session

User preference

Deployment slots

Features as a service

Conclusion

App offline strategies for your website

app_offline.htm

IIS Rewrite

Maintenance manager

Limited downtime?

Using Models Builder in an Umbraco project

Structure

Using the models

Compositions

ModelTypeAlias

Summary

Further reading

Upgrading Umbraco

Why Upgrade?

What's the process?

Conclusion

Continuous delivery for .NET (revisited)

TeamCity

GitVersion

Octopus Deploy

Lifecycles

3.0

Awesome Umbraco

Next steps

Continuous delivery for .NET (part 1)

Simple guide

TeamCity and Octopus Deploy

Example setup