Single entry point

· 561 words · 3 minute read

Getting started working on an unknown repository can be daunting. Getting all the tools, setting up your environment, running the tests, building the artifact, deploying the new version of the software…

All those can take a lot of time and back and forth with other colleagues who are used to working there (hopefully they're still working in your company) just so that you can get started working.

If you're lucky, you will find scripts for those actions. You might only find an example of an arcane command in the README that has not been updated in the last 2 years. Or you might not encounter any indication of the direction in which to go.

Hopefully, this new repo has the same structure as the last 4 you had to open to change a single line.

Let's take a look at a better way.

A consistent place to look at

By creating a single command that will list all the actions that are available in your repository, you can alleviate most of this issue.

Let's use Invoke to make this possible

$ invoke -l

install-dependencies
run
build.binary
build.docker
test.all
test.unit
test.integration
lint
get.version
deploy

Here, you have all of the available actions for your repository.

You just cloned the repo and want to get started ? Ensure that the tests actually pass first

invoke test.all

This command being self-contained, it will install all required dependencies, create the correct environment if necessary, and run the commands to run your tests.

Then when you want to know more about a command, you simply

$ invoke -h deploy

Docstring:
  Deploy program to a given environment in a given region

Options:
  -e STRING, --env=STRING      Environment to deploy in [dev|stage|prod]
  -r STRING, --region=STRING   Region to deploy in [europe|us]

One command to rule them all

With such a command, integrations with other parts of your system become easier.

CI config goes from hundreds of lines of infrastructure-application-ci entangled code to a single explicit command that you can test locally. Your pipelines are composed of an explicit list of commands that, when run locally, will give the exact same result. Is it not simpler to debug ?

I want back this time spent dancing with commits around my CI because there is no other way to debug it than to run the code in its specific environment. Of course this won't remove the issue completely, but it will mitigate it.

Your entrypoint sets up its own environment when running commands. Give it a way to export this environment so that you can run the default toolchain of your language easily. This way, you can even use new tools without having to integrate them into your entrypoint, although it would be very easy to do so.

Your editor can hook up into this entrypoint to run the exact same commands. Then, you use the shortcuts you're used to and trigger the exact same commands that would run on the CLI or in your CI.

Get started

You don't need permission to do this. You can start by creating a simple command to make your life easier, like starting and integration test environment. Keep adding helpful tools to make your life easier.

You will probably replicate some functionality, and that's ok. At the very least, it will help you understand better how those work and find ways to improve on them.