Babashka

You should be familiar with the official documenatation of Babashka . BigConfig doesn’t have a CLI and you will use Babashka and Clojure Tools to interact with it from the shell.

Monorepo example

We will use the multi template to show how Babashka is used by BigConfig. This template allows to have multiple module and profiles.

Create the multi repository
Terminal window
```
clojure -Tbig-config multi
```
Shows the Babashka tasks
Terminal window
```
cd multi
bb tasks
```
Show the BigConfig DSL manual.
Terminal window
```
bb show-help
```

BigConfig DSL

To achieve a zero-cost build step, BigConfig has a simple DSL for the shell. This DSL allows you to define linear workflows in the shell and it is more powerful than Makefile tasks.

In the multi template there are 3 modules:

alpha — Hello world in Terraform.
beta — main.tf.json generated with Clojure code.
gamma — Hello world in Ansible.

There are also 2 profiles:

dev — development
prod — production

bb render -- alpha prod

Everything between bb and -- are the steps of the BigConfig workflow. After -- you always have the module and the profile. In this case we are asking BigConfig to build the combination of the module alpha and the profile prod.

bb render exec -- alpha prod ls -l

After the module and the profile you have the command that you want to execute in the output directory of the build step. The order of steps matter and BigConfig will first build the configuration files and then execute ls -l.

bb render tofu:init tofu:apply -- alpha prod

You can have multiple shell commands and every step that is not a predefined step is considered a shell command to be executed in the output directory of the build process. : are replaced with space.

Predefined steps

These are the predefined steps in BigConfig

render — run the BigConfig build step.
exec — execute any command (e.g., ansible-playbook, terraform plan) inside output directory of the build step.
git-check — verify the local branch isn’t behind origin.
git-push — push changes.
lock — acquire a pessimistic lock.
unlock-any — release the lock acquired ignoring the owner.

These predefined steps are enough to replace tools like Atlantis or similar.

Example

Usually teams don’t use Terraform from their dev machines but they use Atlantis or similar to achieve coordination. They trade productivity for safety. This is not necessary with BigConfig. You can have multiple developers making changes to the same infrastructure from their dev machines and have coordination too.

bb render git-check lock tofu:init tofu:apply:-auto-approve git-push unlock-any -- alpha prod

render — It will render the configuration files. If there is an error in the code and the configuration files cannot be generated the workflow will stop and show the error so that the developer can fix it.
git-check — It will check that we are not behind origin and the local working directory is clean.
lock — If the previous steps are successful, now it makes sense to acquire the pessimistic lock to block other developers from making their changes in parallel.
tofu:init and tofu:apply:-auto-approve — These are the commands to apply the changes. They can be interactive or not.
git-push — Usually the developer prepares the commit before making the changes and this step automates the push of the commit.
unlock-any — All the previous steps were successful. We have made the changes in isolation and we have pushed them to origin. The three environments working directory, origin, and infrastructure are aligned. Therefore we can release the lock so that other developer can also make changes after us.