One of the uses of ops is to create development environments that work across platforms and with variable configuration options (fed in as inputs). Some of the benefits of this approach are:
- It's powerful: ops are parametrized processes running in containers, so the local environment setup sequence can include anything from seeding DB data to fetching secrets and provisioning cloud services.
- It promotes reusability: Because ops be referenced remotely and run anywhere, an op can be written once and used many times in different services or projects.
- It's portable: all ops live next to the source code of your service, and so are versioned along with the source code they run.
- It's uniform: one operational interface (
opctl run devor
opctl run test... etc.) can be used regardless of programming language or tools used. The specifics of the underlying tools are abstracted away inside the ops. This is especially useful in an environment where multiple teams work on polyglot services with different build tools.
To group ops related to a code repo, opctl observes a convention where it will by default look for ops in a directory called
.opspec in the current working directory.
You can run
opctl ls in your terminal to see all available ops for your project
Usage: opctl ls [DIR_REF] List operations (only opspec 0.1.6 compatible operations will be listed) Arguments: DIR_REF=".opspec" Reference to dir ops will be listed from