At HiP, we use GitLab to host our code, and we’ve found their integrated CI / CD pipelines great to integrate with. However, most of the build / test cycle actually happens locally, before we push up to Gitlab.
Thanks to tools like Kubernetes and Docker, our local dev environments almost exactly match our deployed staging and prod environments.
However, after getting a nice slick build pipeline within Gitlab, we found pretty quickly that our local build/deploy experience was lagging a bit behind.
So, we build Tino. Named after the greek god of continuous delivery (or the authors first dog – who was named after the great Faustino Asprilla), Tino lets us run the same build scripts that Gitlab runs, locally on our machines.
There are a few tools that exist in this space already — however, after investigation we found that they were slow, or abandoned.
Tino runs quickly, as we side-step Docker, and just run in the local shell. It has a great tab-based console experience, to help us autocomplete our way to local deployment greatness. And, by matching our local build / deployment process to that running in Gitlab, we’ve found the overall knowledge of our deployment pipeline is improved across the whole team.
Tino in Action
Rather than write too much here are a few examples of using it
Tasks are group by their build phase
Running a task
Parameter defaults are taken from the gitlab-ci file
Parameter values can be overridden
Overrides are remembered
It is also possible to have tasks that are specific to the local environment and not applicable to gitlab by creating a
.local-build.yml file which follows the same format as
HiP is committed to open source, and we recently open sourced a number of our internal projects that we use when building HiP. Tino is one of those, and available on Github here