Speed up your builds to up to 375% and watch for changes for an even faster dev cycle using this workaround on WSL2/Ubuntu
Using Jekyll, from WSL/Linux (Workaround 1)
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.
How to deploy and host a Jekyll website in Azure blob storage using a VSTS continuous deployment pipeline
Infrastructure as code
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.
How to deploy and host a Jekyll website in Azure blob storage using a VSTS continuous deployment pipeline
Part 3: The VSTS Release
Now that we have a Blob Storage container set up for static website delivery, we need to deploy our Jekyll website there.
How to deploy and host a Jekyll website in Azure blob storage using a VSTS continuous deployment pipeline
Part 2: Create Azure Blob Storage, and configure static website
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.
How to deploy and host a Jekyll website in Azure blob storage using a VSTS continuous deployment pipeline
Part 1: The VSTS Build
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!
How to deploy and host a Jekyll website in Azure blob storage using a VSTS continuous deployment pipeline
Introduction and prerequisites
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:
Operation result
Design Pattern
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:
A beginner guide to exceptions
The basics
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.
DataAnnotations Localization using ASP.NET Core 2 and ForEvolve.AspNetCore.Localization
The basics
In the past few months, I worked on a few projects, some are more long terms than others but all in all, I ended up adding a few features to my toolbox: the ForEvolve Framework.
This article will focus on ForEvolve.AspNetCore.Localization
. I will show you how you can enable localization of DataAnnotations
error messages with 3 lines of code. All the usual Asp.Net Core 2 localization plumbing is also done for you.
Design Patterns: Asp.Net Core Web API, services, and repositories
Part 11: Integration testing
In the previous article, we completed the last piece of the Ninja API. In this article, we will glue all of these pieces together by:
- Creating integration tests to integrate the Ninja subsystem confidently
- Connecting the Ninja API to Azure Table Storage
- Leveraging the new Asp.Net Core 2.0 default configuration