Brewing Better Builds with Workbrew

At Level, we write, test, and ship code every day. To manage software packages on our development and production computers, we use the extremely popular Homebrew. (If you're not familiar, brew is a package manager for unix-based computers that lets you install all sorts of software.) However, until now, we had neither security nor observability in managing these packages. Each person had to manage their own computers and if we needed everyone to update a particular package on their device or on a server, our best tool was simply posting in a Slack channel and hoping that everyone read the message. Workbrew now provides us with central management, security, and visibility on all of the various software packages we need to install.

As part of our toolchain, we use a massive make recipe called setup that looks something like this:

setup: ## Setup project, for local engineering
	@echo "${BLUE} == Setting up Local Eng Environment == ${RESET}"
	@echo "----------------------------------------"

	@echo "${PURPLE} -- Ensuring poetry -- ${RESET}"
	@command -v poetry > /dev/null && poetry --version | grep "1.8.3" >
            /dev/null ||
            (echo "Installing poetry 1.8.3..." &&
                pipx install --force poetry==1.8.3)

	@echo "${PURPLE} -- Installing correct python version -- ${RESET}"
	pyenv install --skip-existing
	poetry config virtualenvs.prefer-active-python true --local
	pyenv local
	poetry env use $(shell pyenv which python)
	@echo ""
        ...

In this recipe, we used to have several brew commands that would perform alchemy on each machine. Using make to manage brew solved practical issues for us, since we use Apple computers to develop and then various flavors of linux on AWS with Prefect. However, we had several issues:

1. We had to constantly remind everyone to run make setup.
2. Everyone had different versions of packages installed on their computers.
3. We had no way to catch security issues with brew-based packages.
4. We are permissive in allowing everyone to install additional brew packages, but have no way to monitor, scan, or upgrade packages.

In short: our make-based system was anarchy after the first time the machine was set up. Now, we use Workbrew. Workbrew is centrally managed brew that solves all the aforementioned problems. Instead of updating the Makefile or dropping a message in our #data-engineering Slack channel for everyone to run a mysterious brew command, we can now roll out our favorite packages with a quick click. We can also see any security vulnerabilities, run updates, and maintain consistent package versions on everyone's devices. This setup works across our personal development computers, as well as deployed workstations and EC2 instances.

We currently split our devices into various device groups. For example, we have a device group for our engineering laptops (see below).

Within that device group, we have developed a set of standard packages, as in below:

Once we got all of our devices connected, we can also see any security vulnerabilities along with any relevant CVE information. We have one-click upgrades to patch these security issues.

We're happy to have integrated Workbrew into our stack. Managing software packages for development is a pain. For Apple (and some Linux) computers, brew is the predominant way for this task; since companies do not want to slow down their developers, they are shockingly permissive when it comes to brew packages. Leaving brew setups unmanaged is particularly galling because brew packages have near total system access, so a potential vulnerability is ripe for exploit. It's surprising that no one has yet made a serious effort to corral this ecosystem, so we're glad someone has stepped up to plug this critical hole in the software development lifecycle. The Workbrew team also has a serious brew pedigree, since most of them are themselves long-time contributors.

Finally, we also wanted to mention that the Workbrew team has been very responsive to even the silliest of questions and it's been a real delight conversing with them. Congrats to the team on building a much needed product!