Start here
DevOps in plain language
A deployment tool cannot resolve an unclear handoff. The team needs agreement about who owns tests, production health, incident response and improvements after a failure.
Automation makes repeatable checks and releases easier, but useful feedback closes the loop. A release that passed tests may still cause user-visible problems, so delivery work must connect to operation and recovery.
How it works
Agree on a small change and its checks
Define the intended user outcome, acceptance tests and recovery plan before release.
Build and release reproducibly
Automate suitable tests and package the change so the deployed version can be identified.
Observe and learn
Monitor the user outcome and system health. Feed defects and operational lessons back into the next change.
Illustrative example · Fictional data
Releasing a fictional report-filter change
- Input
- A team adds a date filter to a reporting application. Unit tests pass, but an integration test must confirm timezone handling.
- Process
- Run both checks, release the identified build to a limited audience and watch errors and incorrect date ranges. Keep a tested recovery route.
- Expected output
- A release whose success is judged by correct reports, not just a green deployment job.
- How to check it
- If report ranges are wrong, the development and operations owners investigate together. Rolling back code must also account for any incompatible data changes.
Where it helps
- Reducing fragile manual deployment steps.
- Connecting release decisions to operational evidence.
- Improving handoffs and recovery responsibility.
DevOps and CI/CD
- DevOps
- The broader collaboration and operating approach.
- Continuous integration
- Regular integration of changes with automated feedback such as builds and tests.
- Delivery/deployment
- Delivery keeps changes ready for release; deployment automatically releases eligible changes. Teams should state which they mean.
What each part of the delivery toolchain does
Version control records code and configuration changes. A CI service runs builds and tests so integration problems can be found before release. A delivery pipeline prepares a tested version for deployment; continuous deployment goes further by releasing changes automatically when its gates pass. A manual production approval can remain part of continuous delivery.
Infrastructure as code records the intended environment in reviewable configuration. Tools such as Terraform or a provider’s infrastructure templates help provision resources consistently. Review the proposed change before applying it: a configuration update can replace a database or widen network access just as an application change can introduce a defect.
Container tooling packages the application; orchestration places and manages workloads. Monitoring and observability expose service health and feed incident lessons back into development. Buying every category of tool does not create shared ownership or a reliable release process.
DevOps as a practice versus a job title
As a practice, DevOps connects development and operations throughout planning, testing, release and support. A job called DevOps Engineer or Platform Engineer may focus on pipelines, infrastructure automation, deployment platforms and developer enablement. The title alone does not describe the responsibilities of every organisation.
For a learning portfolio, show a small service moving through a reviewed change, automated tests, deployment and a recovery exercise. Explain who approves changes, where secrets are stored, how a failure is detected and how the previous version is recovered. A successful demonstration should show the feedback loop, not simply screenshots of installed tools.
Related reading and learning pathways
Common pitfalls
- Fast deployment of poorly tested changes can increase disruption.
- A separate team named DevOps does not automatically create shared ownership.
- A rollback command is not a complete recovery plan for irreversible data changes.
Put the idea to work
Try it yourself
Map a small change from request to production feedback. Identify one manual step to automate and one unclear responsibility to resolve; tools alone will not fix the latter.
Common questions
Is DevOps a specific tool?
No. Tools support it, but ownership, collaboration and feedback are central. In practice, DevOps means development and operations share responsibility for building, releasing and running software, supported by automation, monitoring and fast feedback from production. Tools such as Git, Jenkins, GitHub Actions and Terraform support these habits.
Can DevOps work without public cloud?
Yes. The practices apply to software delivered in different hosting environments. Version control, automated builds and tests, infrastructure as code and monitoring work equally well for on-premises servers, private clouds and hybrid environments. Many banks and government bodies apply DevOps practices to systems hosted in their own data centres.
Does every change need automatic production deployment?
No. Release decisions can include appropriate approval gates while builds and tests remain automated. Many regulated teams use continuous delivery: every change is built, tested and ready to release, while a person approves the final production deployment. Automation still runs the checks, so approval is quick and auditable.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.