Path to Production for a DevOps Team

Most teams that I have worked on have been Waterfall development teams. Some of these teams didn’t write much software but rather supported vendor applications. The engineers, for the most part, were good at one thing and one thing only. There wasn’t the concept of Full-Stack ownership and certainly not of operating the software they built. There was no concept of Pair Programming and learning each other’s skills either.

Fast-forward to a more Agile world. Teams completely own the code, the deployment, and the support of that software on whatever infrastructure they choose. You can’t ship-and-forget anymore, nor would you want to since you’ll be the one who has to wake up when your PagerDuty alerts sound off at 3 am on a Sunday morning.

For engineers that have spent their entire careers just writing software, many of the DevOps practices in this new series will be new to them. That’s okay; the point of this new DevOps series of posts will be to illustrate and help guide those who are unfamiliar with concepts such as circuit breaking or observability. As I publish new articles, I will update the bulleted table of contents below with a link.

Table of Contents –

1. Observability
2. Authentication
3. Documentation
4. Resilience
5. Load Testing
6. Health Checks
7. Configuration Management
8. A Note About 12-Factor Applications

I hope you’ll all stay with me as I expand on this list and detail out my thoughts on these topics in the coming days and weeks.