Prerequisite To Learn Devops

Prerequisite To Learn Devops

Reading time1 min
#DevOps#Automation#Technology#VersionControl#Scripting#CI/CD

Prerequisites for Practical DevOps: What Really Matters First

Forget one-click Kubernetes installations for a minute. Reliability in DevOps starts with disciplined habits and core skills. Misconfigurations or outages rarely trace back to “lack of tools”—it's typically a gap in fundamentals.


Version Control: Non-Negotiable Groundwork

Accidental overwrites, lost configurations, broken “collaborations”: these are symptoms of poor version control. Today, Git (recently, v2.42.0 or later is typical) dominates, but knowing why it matters is as important as knowing how.

Key capabilities:

  • Branching strategies (git checkout -b feature/foo, git merge --no-ff)
  • Merge conflict resolution (practice with git mergetool)
  • Reverting: git revert <commit> vs git reset --hard
  • Handling PRs/code review workflows (push to feature branch, open a PR, request review)

Note: Large teams benefit from mastering rebasing (git rebase)—but misuse can rewrite history. Use judiciously; audit with git log --oneline --graph.


Scripting: Automation Over Repetition

Rerunning manual steps leads to subtle inconsistencies—“it worked on my workstation” is rarely a fluke. Every production system is only as reproducible as its scriptability.

Language of choice? In most operational stacks: bash 5.x for shell tasks, python 3.11+ for more complex workflows. Quick sample:

#!/bin/bash
set -e  # Fail fast on any error

declare -a pkgs=(curl git jq)
for p in "${pkgs[@]}"; do
    if ! dpkg -s "$p" &>/dev/null; then
        sudo apt-get install -y "$p"
    fi
done
echo "Prerequisite packages installed."

This idempotent pattern prevents silent skips—no more, “why is jq missing on only one server?”

Gotcha: Default shell on macOS is zsh post-10.15 Catalina. Compatibility issues do crop up (e.g., array handling differs from bash).


System Administration: Know the Substrate

Automation solves little if you can't diagnose OS-level problems. DevOps without operational intuition leads to “pipeline green, site down.” Critically, solid Linux admin skills are mandatory (Windows admins: consider WSL2 or native VMs for parity).

Essentials:

  • Process and disk: ps aux, top, htop, df -h
  • Service management: systemctl status <svc>, systemctl restart <svc> (e.g. nginx, docker)
  • Permissions: chmod 644 somefile, chown user:group somefile
  • Log analysis: journal (journalctl -u ssh --since "1 hour ago"), classic logs (/var/log/syslog, /var/log/auth.log)
  • Simple networking checks: ss -tulnp, curl -v, dig, traceroute

Side note: Watch for limits; running out of inodes causes “No space left on device” even when df -h shows free disk.

CommandUse CaseCommon Pitfall
systemctl restart dockerUnstuck hung containerdFails if unit name is wrong
chmod -R 777 .Quick (unsafe) workaroundRecursively opens permissions
ps fauxTree view of processesOutput can be overwhelming

CI/CD Concepts: Beyond Click-Next Wizards

Any DevOps initiative flounders if delivery looks like, “deploy.sh every Friday—hope it works.” Automation should enforce confidence and reversibility.

Core concepts:

  • CI: Integrate changes to main (or develop) with automated lint, build, test, and artifact generation. Triggers: Push to SCM, PR events.
  • CD: Deploy artifacts through staged environments. Rollbacks should be plan A, not afterthought.

Abstract example workflow:

[git push] → [CI job: test + build] → [Artifact store: S3, Nexus] → [CD job: deploy to staging] → [Manual/promoted deploy to prod]

Tip: Before committing to a tool (GitHub Actions, GitLab CI, Jenkins), map desired states—e.g., “fail fast on test; auto-deploy on tag push.” This clarity avoids sprawling YAML pipelines.


Advisory: Don’t Chase Tools—Build Sensible Habits

There’s always a new orchestrator; last year Docker Swarm, today Kubernetes, tomorrow Nomad. Attempting to master everything before nailing the basics results in shallow expertise and frequent outages.


Non-Obvious Tip

Run a real diagnostic: break your own environment on purpose.

  • Remove /etc/passwd backup, or fill /tmp to full, then recover.
  • Force a merge conflict and resolve it.
  • Write a script that emails when disk_used > 85% and test on a throwaway VM.

Real resilience comes from handling (and observing) actual failure modes, not just reading about them.


Summary Table

Prerequisite AreaImmediate Next StepKnown Issue
Version ControlCreate/push to a private GitHub repoMissing .gitignore causes bloat
ScriptingAutomate a daily admin taskHardcoding paths = future errors
SysadminSpin up/down a Linux VM repeatedlyCloud costs can spike, monitor bills
CI/CDDiagram an ideal deployment pipelineYAML indentation bugs

Final Words

The fastest route to effective DevOps isn’t a checklist of certifications or tools. It's habitually tracking changes, scripting repeatable outcomes, understanding your operating environment, and thinking through the entire path from commit to production. Toolchains will come and go. Disciplined fundamentals persist.

Most overlooked advice: break things in a safe environment and learn from the recovery, not just the setup.

Questions, dead-ends, or non-obvious war stories? Share them—half of DevOps is learning from what didn’t go as planned.