4.4Operations and practice

Automation scripts and CI jobs ultimately run on a shell (bash). So reading precisely "what this command sequence does" is basic fitness for deployment and operations. At the same time, DevOps is not a particular tool name but the culture and practice of breaking down the wall between development and operations to deliver fast and safely through automation and measurement. This section organizes basic bash operations and environment-variable handling as reading, and DevOps principles as the judgment of "why they create value."

4.4.1File and directory operations

• Where am I and what is here: pwd (print the current directory), ls (list contents, ls -l for detail, ls -a to include hidden files), cd path (move, cd .. goes up one). Mistaking where you are shifts how relative paths resolve, so it is safe to check your location with pwd first.
• Create, copy, move, delete: mkdir dir (make a directory, mkdir -p a/b/c creates parents too), cp src dst (copy, cp -r for directories), mv src dst (move or rename), rm file (delete, rm -r dir recursively). cat file prints a file's contents. rm -r is irreversible, so confirm the target before running it.

4.4.2Environment variables

• Environment variables are configuration values passed to a process (an API URL, a target endpoint, a secret, etc.). Set one with export NAME=value, reference it with echo $NAME, and list them with env. Giving configuration from outside via environment variables instead of embedding it in code lets the same image switch between dev and prod (directly tied to the previous section's secret management).
• A variable you export is inherited by child processes started afterward (e.g., an app run after export API_URL=https://api.example.com can read it via os.environ). A variable set as just NAME=value without export stays in the current shell and is not passed to child processes—mistaking this becomes an "the app cannot read its config" failure.

4.4.3DevOps principles

• DevOps is the culture and practice of breaking the wall between development (Dev) and operations (Ops) to collaborate, making releases fast and safe. Its pillars: culture (shared responsibility, blameless improvement), automation (pipeline the build/test/deploy), measurement (turn change-failure rate and lead time into metrics), and sharing (share knowledge and visibility). Adopting a particular product is not itself DevOps.
• How value emerges: automating repetitive manual work reduces human error and wait time, and releasing small and often keeps each change's blast radius small and isolation fast. Measurement is what lets you judge by facts whether "going faster made things more fragile." CI/CD (two sections earlier) embodies the automation of DevOps.

Suppose you inherit a deployment bash script and are asked what this fragment means: it runs mkdir -p /opt/app/logs, then cp -r ./build /opt/app/, then export API_URL=https://api.example.com, and finally starts python /opt/app/build/main.py. Reading it in order: first it creates the log directory, parents and all, with -p (no error if it already exists), then recursively copies the build artifacts as a directory, and sets the environment variable API_URL before starting the app, so the app can read that URL via os.environ["API_URL"]. Now an operator reports "in production, API_URL is not reflected in the app." A common cause is writing API_URL=... without export, while starting the app in a different shell/job. A non-exported variable stays in the current shell and is not inherited by a child process started later, so the app sees it as unset. The fix is to export API_URL=... in the same execution context that starts the app (or attach it as the environment right before the start command). Knowing this small behavioral difference lets you isolate an "app cannot read its config" failure straight from how the shell works. Furthermore, if this procedure is typed by hand every time, the practical judgment extends to a proposal to pipeline and automate it in the DevOps spirit to cut human error and to make irreversible operations like rm -r fail safe. In short, operational quality is decided by the ability to read bash line by line accurately and the DevOps viewpoint of continuously improving it through automation, measurement, and sharing.

4.4.4Section summary

• Bash basics: pwd/ls/cd for location and listing, mkdir (-p)/cp (-r)/mv/rm (-r irreversible)/cat for operations. Check location with pwd first
• Set environment variables with export NAME=value and read via $NAME/env. Only exported variables are inherited by child processes; give config from the environment, not from code
• DevOps breaks the Dev/Ops wall through culture, automation, measurement, and sharing; small frequent releases plus measurement balance speed and safety (adopting a product is not DevOps)