At Trunk, we believe rules for writing secure and clean code should be encoded into the repository and enforced by the computer — not by humans and code review cycles. In fact, we think any repeated critical task that requires a human to remember to do something is destined to fail or be ignored. Trunk is all about automating those things that humans have to remember and hate to do in the software development process.
We built Check as our first “product” within the Trunk platform to address one of the biggest pain points we all felt in our past (and present) lives as developers — manual, inconsistent management of the Developer Experience and developer tooling. In large tech companies like Google, teams of engineers manage developer tooling and are dedicated to creating automation aimed at making developers more efficient. Most companies can’t afford a developer tools (or Developer Experience) team. Check liberates your development team from managing this constantly evolving headache; it standardizes and maintains the DevEx tooling required for your technology and codebase, and makes sure every developer on your team is using the same set of tools, in the same way. More specifically, Check automatically detects languages and technologies in your repos, recommends linters, analyzers, and formatters, and helps you configure them. In the background, Check runs continuously, caching results so they are always available. You might call Check a “meta-linter” and you wouldn’t be wrong. But it’s more than that with benefits like:
Better Security: With Check, everyone on your team will always be running the best and most up-to-date tools on every technology in your repo. Running old versions of open source tools exposes you to security vulnerabilities.
Time Savings and Increased Code Velocity: Check gives engineers back their time by short-circuiting the developer -to -Continuous Integration (CI) loop.
Infrastructure and Labor Costs: Check saves you money by reducing the number of iterations a PR goes through before landing and the compute usage for running tests and checks in CI.
Better Security Through Developer Experience Standardization
We designed Check to plug a huge gap in the secure software development process — making sure that all developers are automatically running the latest versions of the right static analyzers, linters, and formatters prior to checking in their code. First-party code is where the most serious vulnerabilities are created. Yet, in many companies, no one is specifically tasked with selecting the right code checking tools that are the first line of defense against insecure first-party code. Because no one owns it, developers are often left to their devices to decide what checks to run and to keep their developer tooling updated and properly patched. Not surprisingly, this creates scattered coverage and gaps.
Check fixes these issues by automating and standardizing developer tools used on a team: everyone running Trunk is guaranteed to be using the same tools. Equally important, Check automatically updates all the checkers and analyzers to the latest versions and ensures they are running in secure configurations. You wouldn’t want to check in code that you wrote using four-year-old versions of Python nor would you want to check in code that you ran through ancient versions of analyzers and linters. Secure coding is easier if everyone is using the same set of tools, in the latest versions, to check code for flaws and bugs. Check transforms selecting and maintaining developer tooling from a constant manual painful process reliant on the goodwill of busy developers to an automatic step that runs in the background on your repo.
Improved Developer Efficiency, Reduced Costs
There are a million things that sap developer time. One of the silliest is asynchronous continuous integration (CI) that runs code checks in the cloud. Usually, this means developers have to wait 15 minutes for the results of very simple checks, and they tend to wait until they get results back from code they have checked in. As often as not, if code fails to pass through inline CI checks (again, linters and analyzers), the flaw is stupid simple — maybe a comma or bracket is missing. If you had known about that before you checked in the code, you would have saved 15 minutes. Repeat this several times per day, and you get a major pain point — one that saps hours per week from each developer and is among the worst offenders in slowing down code velocity, To put this in perspective, you would never tolerate a spell check that took 15 minutes to tell you that word was misspelled. We think you shouldn’t suffer from CI-based linting that takes 15 minutes to tell you if something in your code is improperly formatted or doesn’t pass a linter test.
Check moves those processes to the environment where you are doing the coding, be it your local box or your cloud environment. By running checks locally, developers can quickly determine if it will pass and fix small problems that add up to inordinate wastes of time and energy. We believe that the cumulative impact of fixing all these small wounds will be to meaningfully accelerate how fast you ship code and to noticeably improve the lives of your developers. Not to mention, reducing time spent on code review. We also think that Check will save your organization money; each CI job running in the cloud fires up multiple virtual servers or small instances, each costing money. By shifting key responsibilities held by CI left down into the developer environment and making them part of DevEx, we believe this will also reduce the complexity of your continuous integration processes so your DevOps team can spend more time solving bigger problems.
Changing How We Code By Automating the Boring Stuff
Check is the first of the “products” and features we will be talking about as we introduce Trunk to the world. But hopefully, from this post, you are getting a sense that we are building a product based on some strong opinions we hold about improving software development. We take inspiration from the DevOps movement and the idea of infrastructure as code. At the core of DevOps is the idea of automating manual processes that invite human error, and scripting best practices in configurations and code. For DevEx, we believe a similar movement is afoot. Yes, developers are highly opinionated about aspects of their experience — their coding environments, the operating system they use, the brand of their laptop. But certain things in DevEx should be treated as infrastructure — standardized, codified, and automated. Moving in this direction will give developers back their time, generate more secure code, and save money. Check is the first step we take on that journey. Install it on your repo and let us know what you think — and stay tuned for other posts on why we built it.
