We have nine working scripts, each with its options, its configuration and its own way of being invoked. That is not a product: it is a folder. A colleague joining tomorrow does not know which one to run, the help is scattered across nine different --help outputs, installation is "copy this and remember the permissions", and nobody knows which version is running on srv-veloz-02. This last project turns the collection into veloz-ops: a single command with subcommands, installable, configurable, versioned, tested, deployed across the fleet and documented. It is the close of the course, and the step that separates "I can program in Bash" from "I have shipped something".

1. The toolkit seen whole
2. The single-command-with-subcommands pattern
3. Final reorganization of the repository
4. Unified configuration and veloz-ops config
5. Bash completion
6. Idempotent installation
7. Semantic versioning and veloz-ops version
8. Quality before deploying
9. Fleet deployment and rollback
10. Documentation: README and runbook

The diagram shows the property we are after: one entry point, one shared library, one configuration. The scripts move into libexec/ because they stop being a public interface; nobody invokes them directly, veloz-ops invokes them.

It is the pattern of git, systemctl or docker, and in Bash it is implemented with case and functions (04-05):

Three decisions. exec replaces the process instead of creating a child: it saves a process and, more importantly, the exit code and the signals reach the real script with no intermediary, so Ctrl-C on veloz-ops backup really interrupts the backup. The case is an explicit allowlist (08-03): building the path as "$LIBEXEC/$sub.sh" would be shorter and would let anyone run veloz-ops ../../bin/whatever. And an unknown subcommand exits with code 2 and writes to stderr, following the 05-03 convention.

The criterion is worth stating out loud: bin/ is what the user invokes, libexec/ what the program invokes, lib/ what is loaded with source and never executed, etc/ what is edited without deploying. That last phrase settles the doubts: if changing it requires code review, it is code; if it is a path, a threshold or a list of targets, it is configuration.

The 05-06 precedence —default < file < environment < options— is implemented at a single point in lib/common.sh, and it is made auditable by storing the origin of every value:

${!env_var} is indirect expansion (03-06): it builds the name VELOZ_DISK_THRESHOLD and reads that variable. Storing the origin alongside the value costs one more associative array and answers the question that eats hours in production: "the threshold is at 95, but the file says 85, where is that coming from?". veloz-ops config prints it in three columns —key, value, origin— and that is why it is a first-class subcommand and not a debugging echo.

COMP_WORDS and COMP_CWORD are the variables Bash fills in when you press Tab, and compgen -W filters a list by the typed prefix. It is not cosmetic: completion is the documentation people actually read, and it prevents half the typing mistakes in a delicate subcommand like restore.

install.sh must be runnable a hundred times with the same result (07-02):

install instead of cp + chmod because it creates the destination and sets the permissions in a single operation, and it is idempotent by nature; ln -sfn overwrites the link without complaining; systemctl enable --now enables and starts, and repeating it does no harm. The key line is the conditional: existing configuration is never overwritten. An installer that overwrites veloz-ops.conf wipes out the thresholds somebody tuned at three in the morning; that is why the repository versions veloz-ops.conf.example and not the real file (08-04). Uninstalling is symmetric: --uninstall stops and disables the timers, deletes the units, runs daemon-reload, removes the link and the tree, and keeps etc/ and the backups, saying where they are left.

The version comes from Git, not from a constant somebody will forget to update (08-04):

git describe --tags --dirty gives v1.4.0 on an exact tag, v1.4.0-7-gab12cd3 if there are seven commits on top —which instantly reveals that there is something unreleased on that server— and adds -dirty if there are uncommitted changes, which in production is an alert in itself. install.sh also writes a VERSION file for deployment via rsync without a repository.

A single script gathers all the checks from module 8:

The order goes from fast to slow: bash -n takes milliseconds and rules out a syntax error before spending thirty seconds on Bats. shellcheck -x follows the source calls so it also analyzes lib/common.sh (08-05), and -S style raises the bar above errors. shfmt -d does not reformat, it only shows the difference and fails: in CI you must fail, not fix things by surprise. The Bats battery is extended to the subcommands (08-06):

The second test is the most valuable in the toolkit: it verifies that dry-run mode has no effects, which is the promise anyone leans on before launching a backup with --delete. The pre-commit hook (08-04) runs the first three stages and CI runs the full battery on every branch.

Deployment is sequential and with a post-check on each host: if srv-veloz-01 fails, the second one is never touched, and in the worst case one server is left broken and two intact. ssh -n (07-06) stops the loop from eating standard input, the classic error that makes only the first host get deployed. A tag is deployed, never a branch: git checkout v1.4.0 gives exactly the code that was tested, and the rollback is the same command with the previous tag (deploy v1.3.2). That reverting is identical to deploying is what makes somebody dare to run it at four in the morning. With one caveat for the runbook: reverting the code is trivial, reverting a format change to the state files or the history is not, and that is why that kind of change bumps the MAJOR version.

They are two documents with two different readers and they are part of the deliverable. The README.md is read by whoever arrives new, cold: what it is, what it requires, how it is installed in five copy-pasteable commands, the subcommands with one real example each and where the configuration lives. If somebody cannot install it and run veloz-ops status following only the README, the README is wrong. The docs/runbook.md is read by somebody half asleep with an alert on their phone: it is organized by alert, not by script, with no prose and with copy-pasteable commands.

A script with no documentation is a script only its author can run; and its author will end up on holiday exactly the night it fails.

• Building the subcommand path from the user's argument. "$LIBEXEC/$1.sh" opens the door to ../. An allowlist with case, always.
• Installers that overwrite the configuration. Version .conf.example; the real .conf is only created if it does not exist.
• Deploying a branch instead of a tag. main means something different every hour; a tag always means the same thing.
• A for host loop with ssh and no -n. The first ssh consumes the list and the rest of the fleet is left undeployed, silently.
• Documenting by script instead of by alert. At four in the morning nobody searches for "analyze-logs"; they search for the text that arrived on their phone.
• Tip: run veloz-ops config on the three servers and compare. Unexplained differences between nodes are the origin of half the "it works on this server" incidents.

1. doctor subcommand. It checks the health of the installation itself: dependencies (jq, rsync, curl, awk), etc/ permissions (600), active timers, the age of the last backup and of the last monitor cycle. One symbol per check and a global 0/1/2 code.
2. Fleet status dashboard. A veloz-ops fleet status that collects the status JSON from the three servers in parallel and flags the differences in version, kernel and effective configuration.
3. Open extension challenges. Package the toolkit as a .deb with postinst/prerm and the configuration marked as conffiles; add a veloz-ops api that exposes the reports over HTTP, deciding what not to expose; unify a --json across every subcommand with a Bats test validating each output; and port the toolkit to Debian or Alpine, noting every bashism you have to resolve (08-07).

1. doctor checks nothing on its own: it reuses what is already built.

The nested chk function, which takes a command and runs it, avoids repeating the same if ten times; and returning 0/2 lets doctor itself be watched from watchdog.sh with the 07-04 convention.

2. fleet.sh already runs in parallel, so consolidating the JSON with jq -s is enough:

Detecting the divergence —not listing the values— is what makes the dashboard a useful tool: if distinct_kernels is greater than 1, there is a server that has not been updated.

We started the course typing echo "Hello" in a terminal and we finish it with a product installed on three servers: a single command with subcommands and help, configuration with precedence and auditable origins, completion, an idempotent installer and a symmetric uninstaller, semantic versioning tied to Git tags, a test battery that runs on every commit, deployment by tag with rollback and documentation written for whoever will read it in the small hours. None of those pieces is advanced Bash: they are case, functions, arrays, printf, source and exit codes —the material of module 4— applied with the judgment of module 8. That is the message of the whole course: the difference between a script and a tool is not in the language, it is in the discipline.

It is worth ending with some honesty about the limits. Bash is unbeatable at gluing programs together, moving files and automating the system; it is exactly the right tool for the five projects in this module. It stops being so when nested data structures appear (more than two levels of JSON and jq is no longer enough), when you need unit tests of business logic, real concurrency, sustained floating-point arithmetic, or when the script goes past a thousand lines and every change is frightening. If you find yourself writing an expression parser or a stateful HTTP client in Bash, the signal is clear: it is time for Python, Go or whatever language your team uses. Knowing when to stop is part of mastering the tool, and rewriting a well-structured Bash script in another language is straightforward precisely because it was well structured.

And where to go next. The Bash manual (man bash, and above all its expansions section, which you read end to end once in your life) is the only definitive source. Google's shell style guide, so you can argue decisions with reasons instead of tastes. ShellCheck as a permanent teacher: every warning you do not understand, look it up by its code and you will learn something you did not know. And above all, the thing that really consolidates it: automate your own work. Take that task you do by hand every Monday, write it as a script with set -euo pipefail, give it options, add a --dry-run, test it with Bats, push it to Git and fire it with a timer. That is what the trade consists of, and you already know how to do all of it.