Can 'shift left' in DevOps pipelines go too far?
The primary objective of DevOps is to enhance the feedback system from idea to client and back.
Updated
On this page
Updated November 2026. This was first published on 12 April 2022. The idea is the same. Any number below is what the original piece said then. It is not a new count.
Key takeaways
- The primary objective of DevOps is to enhance the feedback system from idea to client and back.
- Enormous breakthroughs in automation and techniques have significantly lowered the volume of physical labor necessary to advance the release pipeline.
- In a highly competitive environment, mission-critical apps cannot manage going down.
The primary objective of DevOps is to enhance the feedback system from idea to client and back. Enormous breakthroughs in automation and techniques have significantly lowered the volume of physical labor necessary to advance the release pipeline. In a highly competitive environment, mission-critical apps cannot manage going down. The complexity of apps, environments, and infrastructure raises the risk of failure. According to research, a manufacturing outage costs around $5,000 per minute, while a critical software breakdown costs around $500,000 and $1 million for every hour.
We often see a lack of coherence inside the release pipeline. The configuration management and deployment procedures are often very dissimilar on the opposite sides of the piping system. But, shifting operations issues to the left could accomplish much higher production progress.
What Is DevOps Shift Left? #
The phrase “shift left” refers to a DevOps group’s action to ensure security features of the app at the early phases of the development life span as a component of a DevSecOps(collaboration between development, security, and operations) organizational pattern.
Shifting left refers to shifting a procedure from the conventional linear representation of the software development lifecycle (SDLC) to the left. Shift left projects in DevOps generally revolve around two topics: security & testing.
What is Shift Left Security, and how does it work? #
Testing #
Application testing was typically performed in the final stages of development and was sent to security people. When software did not fulfill performance standards, didn’t seem to work, or otherwise didn’t comply with the rules, it was sent back to advancement for further adjustments. It thus led to a massive bottleneck in the SDLC and also was incompatible with DevOps methods, which puts an emphasis on speed of development.
Shift left testing allows for detecting and correcting bugs pretty early in the software development process. This shortens the development cycle, increases efficiency, and allows for a quicker advancement in the security research and setup phases.
Until recently, a security test was carried out after software testing at the end of the development process. At this step, security personnel would conduct static analysis (SAST) and dynamic analysis (DAST) as well as other methods of analysis and security testing.
The outcomes of the application security test would either allow the app to keep moving forward with production release or refuse it and return it directly back to the programmers for adjustment. This ultimately resulted in lengthy development postponements or a heightened incidence of having to release apps that lacked required security features.
Shifting security to the left implies implementing security protocols throughout the design process instead of at the final moment. Shifting security left aims to build the software with best security practices built in and identify and solve possible security flaws and vulnerabilities as early as possible in the design procedure, attempting to make security issues simpler, quicker, and more inexpensive to address.
The other side of the left shift #
In practice, DevOps provides software engineers and designers with numerous measurable benefits. The key benefits are automation, clarity, and pace. Software developers are much more involved in and held to account for the consumer experience from a corporate perspective.
The amount of obligations that each programmer was liable for was growing. In manufacturing, there are many more objects to keep track of. Warnings from internal systems continued to go off more regularly as more characteristics were constructed and installed. Separately, an engineer became responsible for the application’s and fundamental systems’ behavior and attitude, efficiency, safety, compliance, and many other aspects.
Sometimes, this has become an enormous distraction, having defeated the very objective of the DevOps procedure, and that was to eliminate roadblocks for software engineers.
This is a scenario of DevOps gone terribly wrong. Due to a major lack of judgment among software engineers and designers, numerous people just went down a hazardous DevOps route, pressuring software developers to burn out fast. The central tenet of DevOps is that developers should be able to do much more, although not to the stage where they have to invest a lot of hard work. Software development and system operations are still two different types of highly specialized efforts in DevOps. The extent to which coder and operations commitments collide depends on the type of services, scalability, and safety.
Can the left shift go too far? #
Software developers regard DevOps as development and “all the other things.” There are also plenty of work processes that roll in from the instant a programmer tests code into version control. Test methods, integration, further checking, setup, and feedback all are perfect situations. This is a significant body of work that is frequently overlooked and underreported. When you place all of this obligation on the shoulders of members who are solely accountable for the development, things start to go wrong. Incident management, upkeep, as well as other technical activities frequently start piling up as a product ages, leading to reduced cycles accessible for developing the product over the years.
Then there is the situation in which technical staff is solely focused on software development and devotes the most of their free cycle to it. Console operations are then compelled to become a washed-down attempt, consisting of only the minimum level necessary to keep it going. It is a regular phenomenon in smaller teams and startups, especially when something new is being launched.
Conclusion #
To conclude, the benefits of the left shift will surely outweigh the chances of it going wrong. But, for the shift left to be a success, a significant culture shift should first occur, something that necessarily involves a cooperative process. Teams are typically set in their ways of operating. So when they think about changing, they should take into account how methodologies, procedures, expertise, tooling, and some other factors will have to transform. What would be more crucial is the requirements for bringing all of the roles in the company into proper alignment.
Questions and answers #
What Is DevOps Shift Left? #
The phrase “shift left” refers to a DevOps group’s action to ensure security features of the app at the early phases of the development life span as a component of a DevSecOps(collaboration between development, security, and operations) organizational pattern.
Can the left shift go too far? #
Software developers regard DevOps as development and “all the other things.” There are also plenty of work processes that roll in from the instant a programmer tests code into version control.