DevOps is a way to manage SDLC, so you as a DevOps Practitioner (aka Engineer), are responsible for the end-to-end SDLC management.

SDLC consists of the following stages:

  • Planning
  • Design
  • Develop
  • Test
  • Deploy
  • Operate

You, as a DevOps Engineer, work through the infinite cycle and use the following practices to improve SDLC:

  • Infrastructure as Code (IaC)
  • Continuous Integration & Continuous Delivery/Deployment (CI/CD)
  • Observability & Reliability
  • Security Automation
  • Containers & Cloud Architecture
  • Collaboration & Communication

How are they connected?

There are multiple ways to implement SDLC and these practices. This obviously depends on the scale of the product you’re working on, the number of different teams, and the overall organization’s structure.

Planning - What are you developing? An effective SDLC!

You don’t know exactly how it will look in a specific organization. You obviously start small and do an iterative approach. There are multiple ways how you can approach it:

  • Kanban
  • Scrum
  • Shape Up

Kanban gives you a way to emphasize priorities, thus limiting work in the process

Scrum gives you iterative development and quick adaptability with short cycles

Shape up puts emphasis on budgeting and fixed timelines, forcing you to make trade-offs

Design - Well-Architected

The Well-Architected Framework, developed by AWS (but not limited to it), serves as a set of practices for building secure, high-performing, resilient, and efficient cloud-based applications and infrastructures. It covers:

  • Operational Excellence
  • Security
  • Reliability
  • Performance Efficiency
  • Cost Optimizations
  • Sustainability

They are focused on fundamental design principles that enable organizations to utilize available technologies and build bulletproof processes effectively.

Develop - Containers, Infrastructure as Code, Referenced Architectures

The larger the organization is, the more there’s a need for standards. They give you predictability.

Providing Product teams with standardized tooling, such as container and IaC configurations/modules, will enable them to be more autonomous and will encourage ownership.

Your ultimate tool is a Referenced Architecture - a set of predefined configurations that you share with product teams. It’s your product and the teams are your customers.

  • Project Templates
  • Dockerfiles
  • CI/CD Templates
  • IaC

The larger the organization the more there’s a need for abstraction. When you treat teams as customers, you gather feedback and build these referenced architectures in such a way that they can do what they do best - deliver value to the customers, while you do what you do best - enable them.

Test - Continuous Integration

Continuous Integration has been a practice for a while. Still many people confuse it with automated builds and tests. CI is about merging frequently, so you as a DevOps Engineer have to build trust into pipelines in such a way that the product teams can move fast while maintaining the quality.

You do this with automation and shifting left what’s possible without blocking the pipeline.

  • Do SAST testing during Code Review, but don’t block the delivery if it fails, it has to push a comment to let the reviewer decide if it’s worth fixing right now, or later (shift ownership to the team)
  • Run automated regressions/smoke tests to ensure the critical workflow works and constantly prove it
  • Build and cache what’s possible, don’t build what doesn’t have to be built

Deploy - Embrace Continuous Delivery

Deployment doesn’t have to be a technical problem you need to stay late at night for. By treating every commit as if it could be deployed to production now you encourage the following principles:

  • Decouple Deployment from a Release - using Canary Deployments and Feature Flags to ensure delivery happens frequently
  • Embrace failure - it’s better to fix issues faster than pile up changes and release once a month
  • Simple & reliable deployments - complicated tooling and deployment process means more risk and highle potential for failure

In addition to code deployment also address infrastructure deployment. It doesn’t have to be manual. Infrastructure has different lifecycle, but still it has one!

Operate - Do Observability not Monitoring

It’s important to understand what it means for your project to work correctly and not. Triggering all alarms on any HTTP 50x is not a good strategy. Implement observability on 3 levels:

  • Basic Infrastructure Monitoring (your CPU, RAM, Disk, etc.) & Application Logs
  • Platform Level Observability (Garbage Collection, service-to-service latency, SQL latency)
  • Service Level Observability (track business metrics per service)

This approach will ensure that you’re filterin out not important information and base your service’s KPIs on something meaningfull.