DEVOPSdigest

We're all familiar with the process of QA within the software development cycle. Developers build a product and send it to QA engineers, who test and bless it before pushing it into the world. After release, a different team of SREs with their own toolset then monitor for issues and bugs. Now, a new level of customer expectations for speed and reliability have pushed businesses further toward delivering rapid product iterations and innovations to keep up with customer demands. This leaves little time to run the traditional development process. QA can no longer act as a major, individual step ...

Organizations need to show agility in the face of ever-changing economic, social, governmental, regulatory, and technology disruptions. Today, in the near post-COVID world, we can work, learn, and socialize from anywhere. The enterprise boundary has been extended beyond the DMZ to the cloud and to your home. This means we can't have a network perimeter-centric view of security anymore; instead, we need to securely enable access for the various users regardless of their location, device, or network ...

Infrastructure as Code. It's not a totally new concept, but it isn't something that everyone is doing at this point. Some have been doing it for a long time. Some have just started the journey. And some have no clue what it even is. We're going to break it down a bit today, and talk about what it is and some of the common issues, or pitfalls, that come along with it ...

We recently shared several quotes about the importance of DevOps Capability Assessments from DevOps Institute Ambassadors. The insights explored the complexities of ways of working, the importance of completing DevOps assessments as part of the DevOps transformation, and how a good assessment examines the challenges and highlights the potential for an organization on a DevOps transformation journey. Today, we have several additional quotes ...

Developers are getting better at building software, but we're not getting better at fixing it. The problem is that fixing bugs and errors is still a very manual process ... That's because traditional observability tools will tell you if your infrastructure is having problems, but don't provide the context a developer needs to fix the code or how to prioritize them based on business requirements. Also, traditional observability tools produce far too much noise and too many false positives, leading to alert fatigue ...

When I worked in product management at the start of my career, the saying about product development was "cost, quality and schedule: pick two" with the implication that there is an inverse variation between getting product shipped quickly and cheaply, and therefore quality can suffer. Or, if you want a high degree of quality and to ship it fast, it is more costly because it requires more resources. Thankfully, that saying is no longer true. With a DevOps approach, you can get speed, high quality and cost efficiency at the same time. However, you cannot get to a DevOps approach in your systems development lifecycle (SDLC) without test automation ...