Dev Log: My first status update on v2

After announcing the kickoff of a big rewrite last week, I wasn’t sure how to actually get things going. There’s a lot I want to get done, but I also want to do it in a way that tells a story. So it’s important not to rush too fast ahead. Then Saturday, fueled by a fresh pot of good coffee and WWDC excitement, things really took off. Now I have a bunch to share.

v2dev working branch

I created a new v2dev git branch which will eventually become the default. I kept the git history up to this point but removed all files except for the LICENSE, and CODE_OF_CONDUCT. Both are essential and unchanged.

Next, I added a new CONTRIBUTING document. I tried to make it welcoming to new contributors. If you spot an opportunity to improve it, let me know.

website/ in the main repository

The micromdm/website repo had the code for micromdm.io. I moved it into the v2dev branch instead, preserving the original history. I think having fewer repositories will be easier to maintain. Breaking things out into multiple repositories makes sense for large teams, or for projects that appeal to a new audience (micromdm/scep is a good example).

Architecture Decision Records

Architecture Decision Records (ADR) are a way of documenting decisions to capture the context leading up to, and the consequences of adopting the decision. ADRs are adopted in some engineering organizations and I’ve advocated for their use on some teams I work with.

Joining a project that’s been around for a while is confusing. Questions like “Why is this project using X?”, or “Why did you not do Y?” come up a lot. Talking to the engineers (if they’re still around) the answer is usually. “Well that API didn’t exist three years ago.”, or “We tried to do X but it didn’t work. We had a deadline, so we did Y instead.” ADRs help to explain why someone made a specific choice at a specific point in time.

I created docs/architecture/decisions/ as a place to capture these decisions. For now, the only file is a template.

# Title Which Captures The Decision

## Status

What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?

## Context

What is the issue that we're seeing that is motivating this decision or change?

## Decision

What is the change that we're proposing and/or doing?

## Consequences

What becomes easier or more difficult to do because of this change?

I’ll try and publish proposals and their outcomes on the blog.

Go module for v2

In Go, every import outside of the standard library is specified with a URL. To import the webhooks module in MicroMDM use github.com/micromdm/micromdm/workflow/webhook. To hash passwords use golang.org/x/crypto/bcrypt. For MicroMDM, I wanted to reduce the coupling with GitHub, and also give the imports a bit of branding.

go mod init micromdm.io/v2

To depend on a library you would run:

go get -u micromdm.io/v2/pkg/useful/library@v2dev

The @v2dev portion is temporary and points to the development git branch. Specifying it won’t be necessary when I change the default branch on GitHub.

Hosting on Netlify

Up to this point, the website was updated by pushing the compiled Hugo output to a cloud storage bucket. To support micromdm.io/v2 in the import path, I needed something that would serve the go-import meta tag

<meta name="go-import" 
    content="micromdm.io/v2/pkg/log git https://github.com/micromdm/micromdm">

I signed up for Netlify because they make it extremely easy to host a static site and add a bit of on-demand logic with lambda functions. I’ve never used Netlify before, but within an hour I had the entire website migrated and running the vanity URL service.

The website/_redirects files configures Netlify to redirect HTTP requests for v2/* to the lambda service.

/v2/* /.netlify/functions/vanity 200!

The function is a Go binary, compiled with this make target as part of the deploy process:

.netlify/functions/vanity: netlify-functions/vanity/*.go
        GOBIN=$(PWD)/.netlify/functions go install ./netlify-functions/vanity

And here is the code it executes.

I’m not sure I’ll stick with Netlify long term, or if I’m going to end up moving to a cloud provider with more features later. Some of the projects I have in mind also require a database. For now, this was the cheapest (it’s free!) set up and requires no maintenance.