Continuous Integration but Local

If you want people to do something, make it easy.

To get people to contribute to your project, care about your platform, or use that new CLI tool you just wrote, make it easy. There is a tendency for putting complex build configuration, variables and scripts into the configuration for CI/CD tooling that means building a project locally becomes an exercise in reverse engineering.

Makefiles are an obvious choice. We can quickly create some targets for testing and building. We can have a shared Makefile structure used throughout a platform. We can expect the same commands to work across different projects and get up to speed in a new codebase much quicker. This is fantastic for onboarding new hires, team transfers, or recruiting evangelists for your new tool.

Provide defaults configuration values for building and testing that work locally in the same way as in your CI environment. These can be overridden at build time with the release values. I should be able to build your tool locally exactly the same as in the CI system. This will also help if you want to switch CI tooling, you’ll have a more portable build.

Lastly if your project requires complex dependencies then write some tooling that will fetch these, or better still; control the build execution environment. Docker makes this trivial and anyone who can run a container can build your tool with the same dependencies. There is a whole ecosystem of tooling now, like Bazel, Earthly, and Dagger that provide guarantees of reproducibility and hermetic execution environments.