ForEvolve

During the summer of 2018, I began writing a book outline with Packt. At first, the goal was a 320-350 pages hands-on book about ASP.NET Core design patterns. Two years and a half later, we have 750+ pages. I can say that I learned many things during that period and that writing a book is way different from what I initially thought.

In this article, we explore how to use VS Code on Windows and use the Linux file system to watch for changes in an improved dev workflow that I described recently in the first article about this subject.

Craig Loewen tweeted me a comment that lead to this even better solution, fixing the same problem and fixing the only drawback that I found. Good thing that one of my 2020 resolution is to use Twitter more!

That said, we still use a Jekyll project, Windows 10, WSL2, Ubuntu 18.04, and Visual Studio Code. We still can apply the same technique to webpack, gulp, or any projects that require watching the file system for changes. We still benefit from a significant speed boost when running commands, like build, of up to 375% (and maybe more)! But we also get all of the VS Code tooling to work (like the Git).

In this article, we explore a workaround to watch for changes using a Jekyll project, Windows 10, WSL2, Ubuntu 18.04, and Visual Studio Code. We can apply the same technique to webpack, gulp, or any projects that require watching the file system for changes. Moreover, I noticed a significant speed boost when running commands, like build, of up to 375% on the Linux file system directly.

I’ve got a good idea from a reader, and I decided to move forward with it: Infrastructure as code.

In this “article” (if I can name it that), I give you the YAML code that you can use to automatically create the build definition by adding a .vsts-ci.yml file to your Jekyll website.

The cool thing about the “infrastructure as code” mindset is the fact that you can manage your infrastructure as if it was any other code. So you can use Git, VS Code or any other coding tool you like. It can also facilitate collaboration, and it does facilitate reusability (and in our case: sharing).

Unfortunately, only the build definition can be shared this way right now. However, Azure does support the deployment of infrastructure as code. You can create Azure resources using ARM templates. Sadly, at the time of this writing, Azure does not support “Static Website (preview)” in the ARM, so I can’t give you that code.

Now that we have a Blob Storage container set up for static website delivery, we need to deploy our Jekyll website there.

Lets recap: we have a Jekyll website saved in VSTS/Git, with a build that starts automatically each time someone pushes code to the master branch.

From there we need to deploy our website in the cloud! However before automating that, we need to create some resources in Azure. To do so, let’s use the Azure portal.

Now the fun begins, we have a website to deploy, a VSTS project and a Git repository. It is time to start that continuous deployment pipeline we want to build!

In this article series, we will create a continuous deployment (CD) pipeline using Visual Studio Team Services (VSTS) to deploy a Jekyll website to Microsoft Azure.

We will use Azure Blob Storage to store and host the files in the cloud, a Content Delivery Network (CDN) to deliver those files using a custom domain (with free HTTPS support). From Blob Storage, we will use the Static Website blade to configure a default page (index.html) and an error page (404 Not Found).

Azure Storage is a great, cost-effective, cloud storage offering from Microsoft (and no they don’t pay me to say that). For example, the images of this blog are delivered using a CDN and stored in Blob Storage on Azure. Moreover, as a developer, I enjoyed my experiences working with both Azure and Jekyll.

That said, I initially planned a single article, and once again it became very long very quickly, so I decided to split it into smaller chapters to make it easier to read. You can still consider the whole series to be a single long article. For example, when I decided to split the article, I had 55 screenshots; only that made the page ultra long.

The articles focus on the DevOps part of the equation and how to implement the cd pipeline, not really on Jekyll itself.

Here is a diagram that explains the whole idea:

This article will focus on the “Operation Result” design pattern, as I call it. Why do I said, “as I call it”? Because it doesn’t seem to have an official name yet; I haven’t read anything about it; and as you will see, this name fits well. I saw this technique used in multiple SDK, and I used it myself numerous times. It is also straightforward to implement and powerful enough to be worth mentioning.

What’s a design pattern?

A design pattern is a way of solving a problem; a sort of plan of how to implement a solution.

Role

The role of the Operation Result design pattern is to give an operation (a method) the possibility to return a complex result (an object), allowing the consumer to:

Today we will take a look at how to propagate errors using Exceptions. I will do my best to keep the article as simple as possible with lots of code samples. I believe that learning the basics is essential in programming.

Prerequisites

You must understand what is a class, a type, a property and have a basic knowledge of inheritance.

What is an Exception?

An exception is a particular Type representing an error.