I recently watched a video where the creator discussed using devcontainers for everything. The idea is that if they get a new PC, they can just clone a repository and have all their development tools set up right away. I'm considering this approach instead of manually installing Azure CLI, PowerShell, Python, Go, etc., especially for when I get issued a temporary or new laptop. Has anyone here tried this? I'm thinking about having one comprehensive devcontainer or creating multiple ones for different tools, including older versions of PowerShell. What are your thoughts or suggestions?
6 Answers
Absolutely, that’s the idea behind devcontainers! Just include the manifest in your project repo, and once someone clones it, they can walk away while the container builds. They'll have a fully functional environment set up in just a few minutes. It simplifies the onboarding process massively.
I customize my devcontainers based on what I’m working on. They can indeed be set up to communicate with your host system, allowing for local service deployment during development. This will help streamline the process without constantly switching containers.
That sounds awesome! Can you share resources or examples of how to set that up? It would definitely save time!
You might also want to check out Nix. It’s another great tool for managing development environments.
That’s been a common practice long before devcontainers, just with VMs. The real question is how much you want to pack into your dev containers. For lighter workloads, sometimes all you need is just a text editor and a couple of tools. Personally, I prefer using Ansible to configure my workstation instead of relying heavily on devcontainers. Everyone has their own workflow, though!
Just a heads up, while containers are meant to be stateless, you have to think about data storage. But you can easily use online storage solutions or set up volumes to handle the persistent state.
Using GitHub Codespaces with devcontainers is a game changer! You can work directly in the browser, just like in VSCode, from anywhere. I’ve even fixed issues from my phone while on the go—definitely worth exploring!
And if you use the same image that your pipeline runs on, it’s even faster to onboard since the image is already built. Plus, it ensures consistency between your local environment and the production pipeline.