31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# ops/
|
|
|
|
The ops/ directory is intended as a semi-organized dumping ground for various types of programs and scripts that exist around the application, but are not actually part of it. (E.g., they will not get deployed, but they might be used *to* deploy the app.)
|
|
|
|
It's intended to be neither totally chaotic, nor totally pristine.
|
|
|
|
Stuff in this directory is expected to begin life as crappy Shell scripts, and, depending on needs, possibly evolve into e.g. Python or Go programs.
|
|
|
|
It can be used for
|
|
- development tools and helpers
|
|
- build and CI scripts
|
|
- unwieldy integration tests
|
|
- environment setup / teardown
|
|
- recurring complex operations that are part of the dev flow (e.g., testing out the schema of an external API)
|
|
- data visualizations
|
|
|
|
## Purpose
|
|
|
|
This is an experimental pattern that I'm trying out. It's basically like "scripts/", but it follows the "3-letter top level directory" convention.
|
|
|
|
It's also less constraining than "scripts", which would appear to disallow things like full Go programs, which I explicitly want to allow, and would actually consider desirable.
|
|
|
|
Shell scripts are fragile and finicky by nature. For example, any kind of error handling is notoriously difficult in Shell. Yet, error states are *extremely common* in anything that you're using Shell for:
|
|
|
|
- network failures
|
|
- some file doesn't exist / already exists
|
|
- permission denied
|
|
- some string variable is empty
|
|
|
|
Therefore, it's natural that important tasks should eventually be implemented using a proper programming language. Beyond a certain level of effort, "Just write it in Go" is actually easier. Or at least Python.
|