Aug 27, 2024
How We Used Devbox to Onboard New Devs Rapidly
From their first day my two Software Engineering interns contributed code to our software project with a complete programming environment setup through the use of one command, all thanks to my current favourite piece of software, Devbox.
Every so often a software application amazes me, Devbox 100% hit the sweet spot.
For any software devs out there we all know the pain to setup up a development environment and onboard new employees. Simple in theory, a mess in practice.
This whole process saved me $1000’s in wasted engineering time all for a total cost of $0 to my business.
Let’s Go Back to Go Forward
Prior to founding Sanico Software I worked as a Software Engineer at several large private and public firms which includes IBM, the Australian Federal Government, and others. I remember when I started as an intern they sent me the link to the GitHub repo, pat me on the back, and said good luck.
Even worse, at another internship the team denied me access to the main repository because they claimed it required an excessive amount of time to onboard someone.
I remember at one large firm on the first day I downloaded the code and asked my mentor:
Me: “What version of Node and NPM do I download?”
Mentor: “Ummmm I don’t know, the latest?”
I downloaded and installed the latest version of Node and NPM but the project failed to execute. As an intern I felt bad to speak up, instead I tried everything until I downgraded Node and the code finally ran.
Ok the code ran… ERROR ERROR ERROR. I failed to install Java. No one documented that I required Java, the team knew but failed to write it down. Oh yes, the painful reality of the divorce of knowledge.
No stress, I installed Java. BOOM… ERROR ERROR ERROR. God help me. A configuration error, I read the code and discovered I failed to set an environment variable.
Error after error for 2 weeks until I ran the project without hiccups.
I wasted not only 2 weeks of my time but the time of my mentor. If my mentor helped me for 2 hours, then it wasted 4 hours cumulatively. 2 hours of my time and 2 hours of his time.
Ahhhh, the unavoidable pain to setup the programming environment in every software project. A reality we developers must accept. Enter my hero and saviour, minus the cape, Deeevvvvboooooxxxxxxxxx.
Fast Forward 8 Years
I now run my own software firm called Sanico Software and wanted to onboard two new Software Engineering interns. I wanted them to contribute to an internal application I created that utilised Rust, Node, NPM, Go, and a bunch of other software dependencies. Not only that, the project required environment variables, auth tokens, and other minor software configurations.
I loathed my experience when I worked for other software companies and wanted to avoid the same experience for my new interns. I set out on a journey to find a solution.
I discovered a range of interesting solutions but none of them covered everything. I wanted something that allowed me to version control the packages for the relevant software dependencies, list the necessary environment variables, run a development build on any major operating system, and to execute the project with one command. One terminal, one tab, one command. A developers dream.
Enter Devbox, created by the fantastic developers at Jetify. The best piece of software I have personally used in my programming lifetime thus far.
Best of all, with one command it installs the environment necessary to execute my software project in isolation of other software installed on my system. More on this later.
Let’s start wth the README.md to illustrate how I utilise Devbox for my software projects. I list one command each to develop, build, test, and publish the project to production:
# To develop the project
$ devbox run dev
# To build the project
$ devbox run build
# To test the project
$ devbox run test
# To publish the project in production
$ devbox run publish
I list no other instructions except a few environment variables and auth tokens required to execute the project.
A new developer pulls the GitHub repo of the software project, installs Devbox globally, sets the correct auth tokens, and executes the project. Devbox takes care of the rest.
To give a taste to other devs out there I will begin from the devbox.json file. This file acts similar to a package.json file in the NPM JavaScript world, a programmer pins the software packages required for the project in their devbox.json file:
"packages": [
"[email protected]",
"libiconv@99",
"[email protected]",
"[email protected]",
"[email protected]"
],
A website called Nixhub, maintained by the Devbox creators Jetify, lists available software packages possible to install. To add a package to the software project I execute the Devbox command-line program with the command: devbox add package_name@version_number. For example, say I wanted to install a specific version of Go, I write: devbox add [email protected]. This then adds go to my devbox.json file as seen in the example above.
The packages section of the devbox.json file provides an explicit, declarative, and actionable list of the packages. For my software projects I previously attempted to capture package version numbers in the README.md file:
Please install the following packages on your operating system:
- Node: 22.2.0
- NPM: 10.8.1
- Go: 1.25.5
... etc etc
The problem with the README.md method? The developers forget to update the version numbers or fail to add new packages in the list and therefore it all becomes one big lie. But this pales in comparison to my biggest pet peeve, global development versions.
Developers install packages globally on their system all the time. As a Software Engineer myself I develop many projects that all require various versions of Node.
One project utilises Node 16, another Node 22, and the other Node 18. As I switch between projects I must remember to upgrade and downgrade my version of Node manually or with a tool like NVM, otherwise I run into strange errors. The onus lies with the developer to remember, in summary, not a good idea.
We all know the danger of global variables in the JavaScript world and other programming languages. It baffles me why we tolerate it for our development environments.
Step in Devbox!!!!
When a developer runs Devbox it computes the environment, saves a cache in the local directory of the project, and sets the environment variables to utilise the locally installed version of packages instead of their global counter part. Hence why Devbox advertises the word “isolated” development environments.
For example, say I installed Node 16 on my local computer it shows the program exists globally within my /usr/local/bin folder:
$ node --version
# 16.0.0
$ which node
# /usr/local/bin/node
Global, yuck.
Instead, when I enter the Devbox environment in my software project it will point to my isolated version of Node instead of the global version:
$ devbox shell
(devbox)$ npm --version
# 22.0.0
(devbox)$ which node
# /Users/.../PROJECT_NAME/.devbox/nix/profile/default/bin/node
This allows me to enter different software projects, run Devbox, and forget the requirement to change my version of Node or other software dependencies.
No tricks, no Docker, no virtualisation, no BS. It utilises Nix under the hood. I will not give an in-depth explanation of Nix as it deserves its own lengthy article. Devbox provides a layer of abstraction on top of Nix to allow the ease of an NPM like isolated and reproducible install experience without the necessity to understand the complexity of Nix.
A Day Not a Week
After my discovery I setup Devbox for my software project, ready to onboard my interns. I successfully utilised Devbox to abstract away the painful process to install Rust, Go lang, and a bunch of other software dependencies. I wanted them to develop the software project not pedal in circles with endless errors through misconfigured global environments and software packages.
Therefore, when my interns started they installed Devbox, pulled the GitHub project, and successfully committed code to the repository on their first day. Devbox allowed them to focus on the code, not the boring configuration steps. A significant accomplishment when compared to my 2 weeks of torture experience as intern many years ago.
Not only that I saved the back and forth interactions between myself and my interns to help setup their programming environment. As a business owner this saved me $1000’s in wasted developer time.
Even better, as I update the dependencies within the devbox.json of the project and push it to Github all other developers receive the update when they pull.
For example, say another developer updated Node from version 16 to 18 within the devbox.json and they pushed it to Github. When myself or another developer pull the change Devbox recomputes the isolated environment and runs again without problems, like magic. Yes, magic I say!!
Sure, I hit a few initial speed bumps with cross-platform development on Windows and macOS but Devbox addressed those concerns with platform specific packages. Once I added the fixes to my devbox.json on the main GitHub repository it resolved the problems for anyone who pulled the latest change on Windows. Again, declarative and reproducible.
How is this thing free!
I applaud the Devbox team from Jetify. I do not know them personally, nor am I affiliated with them in any shape or form. I wrote this article to share my Devbox success story with the world and in appreciation to the team at Jetify of their generosity to build Devbox and make it freely available and open source to the developer community. They offer commercial cloud services, which I 100% support. If it helps further support the development of Devbox and adds optional and external premium features, then why not?
At my company it saved endless hours of an engineering time which equates to thousands of dollars saved. All those savings without a dollar spent except for my one time effort to setup Devbox, what an invaluable tool.
I recommend any software developers out there to try out Devbox. It’s a beautiful, pleasant, and delightful Nix abstraction that creates reproducible and isolated development environments.
I showed a small subset of features of Devbox, I hope to write further articles on its features and how we utilise it here at Sanico.
Checkout Devbox here: https://www.jetify.com/devbox/docs/
P.S. Shout out to John Lago and Mike Nikles from the Jetify Developer Community Discord for their help with a few platform specific issues that occurred when I first used Devbox.