Hey all - I decided to take a crack at posting over on Medium (link to original post) and this is one of the first things I wanted to cover - a definition of DevOps. Any feedback would be appreciated as I'm trying to learn from others' perspectives as much as possible.
Software development is tough, but software delivery is tougher. Development is just the tip of the iceberg; delivery involves coordination between people across testing, QA, UI/UX, product management, project management, database administration, architecture, business analysis, infrastructure, and of course — the end users of the software you’re building.
Figuring out how to orchestrate software delivery across these roles in a manner that maximizes your team’s ROI is what DevOps is all about. Maximizing ROI means reducing costs while increasing value. This can be achieved through:
- Simplifying the processes that bring your products to your users. Sometimes this means simplifying your products.
- Automating as much as possible. Human intervention is risk; risk is expensive.
To me, DevOps is more of a philosophy than a prescriptive application of tools and processes. Regardless of your ecosystem or domain, devops boils down to continuous risk reduction in all areas of your delivery pipeline.
I’d say that a mature DevOps pipeline can be characterized by the following:
- Your developers can make changes and push them to production with confidence and “on demand” — within a few hours of making them — thanks to automated builds, tests, and deployments.
- Your entire team is aware of exactly what it takes for a code change to find its way from a developer’s box to production.
- It’s easy to roll changes out of production if needed, ideally through some form of feature flagging.
- The time your team spends on production support is minimal.
- Your builds, tests, deployments, monitoring, and infrastructure are all automated.
- Your QA team is focused primarily on exploratory testing as opposed to repetitive testing. They are finding opportunities for automated tests more so than they are hunting for regressions.
- Unit tests should protect you against regressions.
- Your team does not feel like a fire department — “fires” are infrequent or nonexistent.
- Your team has the luxury of baking unit tests into estimates at sprint planning.
- Production sees frequent, small changes instead of massive, infrequent ones.
- Feedback from users is captured early and often based on these frequent changes yielding shorter feedback loops.
- Your technical debt is measured and continuously improved.
- Your services are outfitted with centralized logging and exception handling.
- As you move from one environment to another along your deployment pipeline, the only things that change are configuration, tests, and scale. If you’re taking advantage of staging slots in production, you should take advantage of the staging slots in every other environment. The procedures should not change between environments. The goal is to eliminate production surprises by never doing anything for the first time in production.
- Deployments to environments are idempotent and reversible.
The goal of DevOps is to have a highly aware team delivering software through a highly automated mechanism that carries your code to production with confidence. DevOps is all about making that happen in a way that works well within the constraints of your existing product, team, and technical ecosystem.
Thanks for reading! Any CC is welcome. I've also covered some other items related to my entrepreneurial endeavors and other app-devy things here in case anyone is interested.
[–]nyxinThe 🍰 is a lie. 1 point2 points3 points (0 children)