Polyglot microservices need pre-commit + git
Thanks to Jeremy Keith for the base image! CC BY 2.0
Microservices are great! Or, at least that’s what the internet keeps telling me. There are a lot of upsides, but there are more than a few challenges too.
For example, microservices are a polyglot’s dream. Have a Rails app and a use case where Ruby seems a bit too slow? No problem, microservices and Go are a good starting point.
Sounds great! However, coding in multiple languages brings some hurt, too. A new language means a new style guide. Work at a shop with both a front end Javascript team and a backend Node.js group? Teams working in different domains are likely to enforce their own domain specific best practices.
As you might imagine, it’s a nightmare keeping track of style guides and best practices on a per service basis. If only there were a tool to help manage this mess. Oh, hey there pre-commit!
What is pre-commit?
Pre-commit is an easy way to force linters and style checkers to run locally, on every commit.
Wait a minute.. this sounds a lot like git hooks. Why not use them? Out of the box, git only enforces hooks server-side. Cloning a repo does not include client-side hooks. That means when it’s time for code review, a Javascript shop might find themselves debating semicolons instead of the actual commit. Ugh.
Pre-commit handles that mess. Checks happen on a dev’s local. Now, code reviews can focus on what’s really important: new code!
How to get started
So, want to get started with pre-commit? Cool, it’s easy. Assuming you already have Python installed, start with:
Next, pick a repo and a code checking tool. As an example, I’ve been following the tutorials for setting up a server in hapi + Node.js. I’m calling my project ‘skillet’. Let’s see what adding pre-commit looks like there.
In this case, my linter of choice is eslint. It’s a super fine grained way to enforce styles in Javascript. The first move is adding a config file for our code checker. For eslint, that’s as best done by:
Now I just need to tell git to love pre-commit. All great romance begins with an introduction:
The final step is listing my hooks in a .pre-commit-config.yaml file. This looks something like:
There three basic parts here. The first is a link to a config git repo. This repo tells pre-commit which files to run the checker against, and which version of the checker to use. A full list of already working repos can be found here.
The sha is the version of the repo to target. If you’re pointing at a Github repo, you can find your sha under commits.
Finally, the id should match the id in the config repo’s hooks.yaml:
Cool! Let’s make sure pre-commit works by making an illegal change. In my case, I like two space tab substitution and npm style line endings (no semicolons!).
“I’m a loner Dottie: a rebel.“
Easy! Now when other folks download my repo, they’ll pre-commit install and then boom! Simple style checking, linting, and etc. If some savage tries to terminate with semicolons or use 4-space tabs, pre-commit will stop ‘em dead.
Who uses pre-commit?
Ken Struys, a Yelp engineer, introduced me to pre-commit. Ken and co originally built it as a way to bring sanity back to their code review process.
They’re recent converts to the microservices way of thinking. They felt pain around code checking and style guides, but didn’t see any simple solutions. Pre-commit emerged as a way for them to scratch their own itch. It’s used daily by the Yelp team there, and actively maintained.
So, no excuses. Give it a try!