It was back in 2015 when I first heard of docker, but it was not until 2017 at my first DDD conference where my mind was opened to its powers. I attended a presentation call "Docker FROM Scratch" presented by Aaron Powell and the way spun up dependent services for projects I was working on was changed forever. Fast forward a few years and after trying to get Sitecore to run in containers a few times with no luck, Microsoft announced Windows Containers and Per Manniche Bering released a repository to build Sitecore images. It was looking like the magic experience I was having on personal projects was going to come to my professional life.
Docker is quite utterly game-changing as a developer; whether be it quickly experimenting with new dependent services, to pulling down the exact container that is running in production where you see a bug, the freedom is fantastic. If you have not used docker yet start using it right now, stop reading this blog and GO.
Now that you have started on your Docker travels lets get back to my story.
In another life, I was a Drupal developer, and if I did not dislike PHP so much, I might still be now. As a developer the Drupal experience was liberating; I could pull production data down with a single command, quickly patch Drupal Core with a git diff, and while I was developing Drupal sites, I was introduced to Lando. Initially I wanted to create a Sitecore plugin for this tool, but there were two issues/roadblocks for me. The first was that it seemed to me that it was geared to Linux containers; it has a bunch of really cool features, but some of them were not available on Windows containers. This, coupled with the fact I could not get it working at all with a Windows container, made me drop this aspiration but not the inspiration. The other was it is written in NodeJS, not that I think this is a bad language its just I prefer C# and the .NET Core stack. So I embarked on my own attempt.
Introducing Dimmy. It is the result of a bunch of code experiments I have been doing since the start of the year. This post is not to explain to you how it works; I want to only introduce you to it.
Dimmy aims to be a tool that decorates a developers experience, supports both Windows and Linux containers, be transparent in what it is doing and above all not bring lock-in. I want to ensure that everything that Dimmy does a developer can continue doing even without Dimmy but maybe a bit slower. Under the hood, Dimmy is not much more than plugin management logic, a templating engine for docker-compose files, and a way to manage public and non-public settings. It uses the power of Octostache to generate docker-compose files that are then executed by docker-compose. It also provides several shortcuts to everyday developer tasks like quickly connecting to a running container without all the stress of looking up container IDs. The best thing is you do not need to commit to Dimmy; if you find you dislike dimsims, send the fried meat and vegetable dumpling back to the Fish & Chips shop, take the generated docker-compose file and remove the tool.
Alongside the release of Dimmy as open-source, I have collaborated with my employer to release a plugin for it to bring support to Sitecore builds. Dimmy.Sitecore.Plugin currently allows the generation of Sitecore Dimmy projects. I do have plans to bring much more aimed at the developer experience. These plans include things like automating applying Sitecore startup speed config changes and altering assembly probing so built assets can be bind-mounted right into your container. Docker containers are ephemeral, so let's take advantage of that and apply things at a point where there is little chance it will make it into production while still accelerating you as a developer.