Applying a DevOps Model
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| DevOps-focused Software Engineer | Integrate development and operations concerns, automate build-test-deploy cycles, monitor running systems, improve feedback from production | Treat deployment as an afterthought, separate dev and ops responsibilities, or rely on manual, undocumented procedures | Cloud-native services, continuously deployed web applications |
| Platform / Automation Lead | Design CI/CD pipelines, define operational metrics, connect system behavior in runtime to development decisions | Focus only on code without considering operability | Teams using GitLab CI, GitHub Actions, container-based delivery |
Affected SDLC Phases
If a team chooses this advanced topic, the implementation, testing, deployment, operation, and feedback phases are tightly connected. Every development decision must consider how the system is built, deployed, run, observed, and improved. Teams must explicitly tie actions to DevOps phases such as plan, code, build, test, release, deploy, operate, and monitor.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined features together with explicit operational considerations.
Technical Details
For each feature, the team must state:
- How it will be built and configured
- How it will be deployed
- What operational concerns exist (configuration, resources, failure modes)
Feature definitions must explicitly reference relevant DevOps phases (e.g. code, build, deploy, operate).
Quality
High-quality feature definitions show awareness that features live beyond code and have operational impact.
Features are sorted by priority
Minimum Viable Product (MVP)
Your team prioritizes features considering both development value and operational impact.
Technical Details
Prioritization must take into account:
- Deployment risk
- Operational complexity
- Monitoring or maintenance effort
Quality
High-quality prioritization balances speed of delivery with system stability.
Features' cost and price are estimated
Minimum Viable Product (MVP)
Your team estimates cost including development, deployment, and operational effort.
Technical Details
Estimates must explicitly reference DevOps phases (e.g. build effort, test automation effort, deployment complexity).
Quality
High-quality estimates reflect the full lifecycle cost of features.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working system that can be built and deployed using an automated or repeatable process.
Technical Details
The demo must show:
- How the system is built
- How it is deployed
- That the running system matches the deployed version
Manual steps are allowed but must be scripted or documented.
Quality
High-quality demos show smooth, repeatable delivery and clear linkage between code and running system.
Bug fixing
Minimum Viable Product (MVP)
During development, your team reports and fixes one issue that involves both development and operational aspects.
Technical Details
The bug report must include:
- Where the issue was detected (build, test, runtime, monitoring)
- Which DevOps phase exposed it
- How the fix improves the pipeline or operation
Fixing must improve not only code but also process or automation where relevant.
Quality
High-quality bug fixing strengthens the DevOps feedback loop and prevents recurrence.
User documentation
Minimum Viable Product (MVP)
User documentation reflects the behavior of the deployed system.
Technical Details
Documentation must describe the system as users experience it in its deployed form.
Quality
High-quality documentation matches the actual running system, not just source code assumptions.
Developer documentation
Minimum Viable Product (MVP)
Developer documentation explains the DevOps setup and lifecycle.
Technical Details
Documentation must describe:
- CI/CD pipeline or build process
- Deployment approach
- Monitoring or operational feedback mechanisms
Quality
High-quality documentation makes DevOps practices explicit and reproducible.