WSL2 on Windows 10 has some issues, but I still prefere it to run my docker containers locally. One of the problems which used to bug me a lot was the memory consumption by Vmmem process. The memory consumption goes though the roof. Even on 32GB machine you may run out of memory. I can’t fix the problem, but at least I know how to patch it up. Here is what I do:
In this post, I’m going to configure the continuous delivery process for Azure WebApp (Azure Function in this case, but that’s pretty much the same) with Octopus Deploy. To make it a little bit interesting I’m going to use Configuration-as-Code approach with a brand new Octopus provider for Terraform. Buckle up and let’s get started… Tools Terraform I’m going to need terraform on my machine: Octopus Deploy For this post, I’ve signed up for a free tier of Octopus Deploy SaaS offering.
GitHub Container Registry was introduced on the 1st of September 2020. It’s still in the Beta stage, so it’s rather not recommended to use it in production. However, it offers us free private storage for our Docker images, at least until the end of the Beta period. Private storage, free and unlimited download… looks like a good enough option for local development. In this post, I’m going to configure my local Kubernetes cluster to pull images from my GitHub Container Registry.
Today we’re going to set up a CI/CD GitHub Action with a Container Structure Test step which will help us to enforce the certain quality policies for the images which we build and ship. It’s a good idea to review your docker images. First of all, it can save time, disk space, and money. When our images are lean the build time is reduced as well as the pull and startup time.
My current project has reached the point where we have to manage our infrastructure in a more organized way rather than ad-hoc manual configurations. Current landscape We use a pretty standard setup for a .NET web application. We keep our code in one monorepo hosted in internal GitLab. We use TeamCity to build our code and we use Octopus Deploy to run our deployments to Azure. We have several environments (let’s call them feature, test, and prod) and they all are different.
It’s hard to imagine modern development without continuous intergation and unit-tests. At work I hardly pay attention on the process, it just works: I push code to GitHub, later on TeamCity picks up changes and starts the build, and few minutes after I receive Slack or email notification about the result. However for my personal projects things are different. I’m using free plan on AppVeyor. It works pretty well except the fact that your build might stay in the queue for a while.
This is a long title. Well, the post is going to be long as well. I want to show how you can set up the CI pipeline using free services and tools. GitHub GitVersion AppVeyor As an example I’m going to use my pet project: AsyncSuffix plugin for ReSharper. The reason is that the way you pack and publish R# extensions is slightly different from the regular NuGet package.
It’s very important to collect and track as much information as you can about your system. We have logging, monitoring, reports and analytics. All the systems that we build are not just packages, which are deployed to the server/computer or device. Everything starts with Issue Tracking system and through the code goes to production. The code and the process of coding both look like an important part of the system and it makes a lot of sense to collect and store all the data about code.