One of my passions in the IT space has long been DevOps. Most specifically how we can make the process of getting from ideation through delivery as fast as possible while keeping all of our processes safe and highly trustworthy. I specifically remember reading The Phoenix Project around 2014 as I was managing a major shift in a software company I was leading at the time and simply falling in love with many of the concepts that the then-emerging DevOps movement was surfacing. At the time environment management was a huge focus of our optimizations. In the end, we went from annual release cycles to weekly as a direct result of that focus on efficient environment management. So when I recently ran across the Sitecore Accelerate recipe for using GitHub Codespaces for Sitecore development - it caught my attention and was something that I had to try.
So beyond nostalgia, why did this interest me so much? In the past one of our most frustrating time sinks as a Sitecore partner has been local environment management. We've expended a lot of effort over the years to manage this through varying means and with varying degrees of success. But more and more with the headless paradigm data is shifting to the cloud and a majority of the functionality we are building is architecturally centered in the head app, in most cases NextJS. This has allowed us to simplify our development environments and streamline our development process. The reality is that as the cloud and headless paradigm shift has occurred the requirements of our development environments have shifted accordingly. And as always we are in a constant search for new and innovative ways to work smarter and more efficiently.
To keep our development environments clean and separate the AgencyQ team has been using Microsoft Azure DevBox setups for a couple of years now. This has allowed for isolated development environments, lower fragility, and quicker spinup, and has eliminated the risk of project crossover from human error. So when we saw this new recipe we were intrigued. It was a lighter-weight natural evolution of a solution that has proven to work very well for us. Yes, DevBox has been great for us and still has a place in our dev stack for traditional/legacy projects that require the full Sitecore stack running locally. But for the typical headless project profile - What if you could click a single button and nearly instantly have a cleanly provisioned dev environment ready to go? What if you could do this from any branch without disrupting your work on an active branch? Having fast lightweight weight easy-to-use environments would be such a time saver for our dev team, especially our front-end-focused developers, we simply had to check it out.
Doing this actually ends up being really simple. You create a folder named ".devcontainer" at the root of your repo and then create a file under it named "devcontainer.json" - this file provides the recipe for how to configure the dev box. Generically speaking the recipe provided in the Sitecore Accelerate program works beautifully and is easily ready to go. But I'm picky and wanted to enhance it even further for our specific standards and use case. Diving in was fun because there are a lot of options to tailor GitHub Codespaces to your team. In the end, we came up with a slightly more complex JSON file that did very similar things but added three things key to your team's patterns:
- Focused on the "./src/sxastarter" folder (to be customized per solution, but follows the standard boilerplate convention for an XM Cloud project) - We did this because we will still be making use of DevBox and some of our provisioning scripts when we need full environments, so we are intentionally restricting the Codespace method to be FrontEnd (NextJS) only in our case
- Added in standard VS Code Extensions that our team leverages to make sure that they are consistently available in the cloud development environment spun up in Codespaces.
- Applied standard VS Code settings for things like formatting (TabSize, Default Formatter, etc) to ensure that this was being applied consistently for every developer on our team.
The final result is this file publicly available as a GitHub GIST
Years ago our spinup time for local environments was sometimes multiple days. In recent years we pretty consistently got that down to hours. And now with this approach, we can accomplish it, well near instantly and with zero direct effort.
