What is Shift Left Approach in DevOps?
There have been different software development methodologies in practice ever since developers started formalizing software development lifecycle to improve quality, efficiency and delivery time.
In a typical waterfall pipeline (the traditional software development model), the development lifecycle span across 6 stages.
- Requirement analysis
- Feasibility study
- Product design
- Software development/coding
Even though the model added much-needed “professionalism” into the software development lifecycle, it was far from perfect due to a lack of agility and delay in deployment.
Since testing is performed during the final stages of the development lifecycle, any findings of errors, compatibility issues, vulnerability etc., resulted in a delay in delivery time as the code had to be sent back to the developers for correction.
Another drawback of the traditional model was that it caused wastage of resources. For example, consider that there is a flaw in the product architecture. Product architecture is decided in the early stages of the software development lifecycle. If the fault is identified in the earlier stage itself, the resources and time spent on designing and coding a product that is faulty from the beginning can be avoided.
Due to such flows in the waterfall model, the project heads were forced to find alternative strategies.
What is a shift left approach?
The shift-left approach aims to overcome the drawbacks of the waterfall model.
It advocates that testing should not be assigned to the last stages of the software development lifecycle; instead, it must be moved to the initial stages.
In other words, the shift left approach is nothing but a software development methodology in which testing is performed earlier in the lifecycle. The term “shift left” is used because testing is moved from the right side of the project timeline to the left side (Please refer to the image of the waterfall model).
Why shift left?
The Shift left approach tries to overcome the drawbacks of late testing.
- It aims to identify faults in the requirement analysis, program architecture, design, and coding in the earlier stages itself so that wastages of resources and time can be avoided.
- The model recognizes and promotes the significance of timely testing.
- The model gives importance to the effective allocation of resources.
- It advocates that enough resources should be allocated for testing.
- The complexity involved in debugging is reduced. (Since quality and performance are checked in every stage of the development lifecycle, testing becomes a linear process rather than a one-time, resource-intensive task. Since every major change and integration are thoroughly scrutinized, it is easier to identify the elements that have an impact on quality, performance and compatibility).
- Reduced code coverage and better encapsulation.
- Projects are executed and products are released in a timely manner as there are fewer chances for any major reworks.
- The quality of the product is increased due to the implementation of better approaches rather than easy solutions.
- Due to the efficient use of time and resources, the overall cost of the project is reduced. Also, there are fewer chances for additional costs caused by reworks and late changes in resource allocation.
- Since the product is released within the expected time, there are fewer chances for “missed opportunities”.
- Since chances for a delay in the product release is very less, business lifecycle (Product planning, product development, product marketing and sales) and business strategies are not affected.
DevOps aims at adding velocity to the software development lifecycle without compromising on quality. In a way, both DevOps and Shift left approach aim for the same objectives. So, incorporating both into your product development strategy is a wise choice.
DevOps is a compound of development (Dev) and operation (Ops). Normally you can incorporate testing into the late (Shift right approach) or earlier stages (Shift left) of the development process.
While shift left strategy offer benefits such as better design, fast development time and delivery, better quality etc., better automation opportunities, wider and real-world testing, and better customer experience are the advantages offered by shift right strategy. To improve the effectiveness of both strategies, developers can adopt a common philosophy of “test early, test often and test in silos and production”. This will help the team to find flaws as early as possible, implement continuous testing and have a holistic approach.
Here are a few tips on how to plan and implement the shift left strategy.
When adopting a shift left approach, there are certain things that must be taken into consideration. We can categorize these factors into three categories mainly.
In a traditional model, the budget was not allocated evenly. A major chunk of the budget was spent on design and development alone. This led to apparent negligence of testing and quality assurance.
The shift left approach gives equal importance to each stage of the product development lifecycle. The budget is allocated more evenly, and testing is well taken care of. Here the terms budget and budgeting have a wider meaning. It involves a well-planned allocation of money and time so that every stage of the development lifecycle is strictly implemented.
Testing is a broad term. It involves different techniques and methods aimed at achieving different objectives. Examples of different testing techniques include manual testing and automated testing. Both techniques can be further divided based on their objectives such as load testing, unit testing, integration testing, functional testing, smoke testing, performance testing etc. While adopting the shift left approach, you must make sure that resources are allocated for every testing method and maximum testing techniques are implemented.
The test strategy should be well planned and documented. There should be a clear understanding of what testing techniques are going to be implemented at each stage of the lifecycle and which team will be responsible for the implementation. It is critical that the strategy is universally applied so that there is no wide swing in the quality of the product between each stage of the development lifecycle.
Once the requirement analysis is completed, the team should start planning on how to make the whole process shift left friendly. The plan should focus on incorporating testing as early as possible and implement it in a way that is incremental. The code coverage should be minimum, and encapsulation should be implemented while coding to make testing easier to execute. Also, resources should be allocated evenly across the development lifecycle.
Developers should test their own codes before pushing them to the main branch or QA team. Version control should be strictly implemented and any merging of codes should not affect the quality and performance of the main module. Since it is easier to test individual code modules, participation from developers ensures that the main branch is cleaner and error-free.
Following the same principle, testers should be introduced to common coding standards. They should be familiar with the functionality of the unit they are going to test. That way if they find any small mistakes in the code they are testing, they can correct the code themselves instead of sending it back to the developers. This will help to reduce development time and in fact, this is one of the main principles of DevOps. DevOps encourages developers to take participation in testing and testers to take participation in designing and development. They don’t have to be an expert in everything. However, expertise in one’s own field and a basic understanding of the whole development lifecycle are very much appreciated.
The QA team should also participate in any planning discussions. This will help them to understand the objectives of the projects better as well as the product design. This knowledge will help them to see whether it is the actual design that is being implemented into a final product. The presence of the QA teams in discussions will also help the other teams as testers can give a clear image of challenges that are most likely to emerge.
The left shift strategy focuses on implementing testing from earlier stages of the development lifecycle. Instead of pushing testing to the final stages, it should be implemented from the unit level itself. This will help with avoiding common bugs and debugging complexities by keeping testing coverage to a minimum level. Also, since DevOps can heavily rely on automation, early testing is critical for proper implementation.
DevOps emphasises team collaboration and multilevel participation. This is very much aligned with the principle of shift left approach that encourages testers to participate from the early stages of the development lifecycle. However, for the successful implementation of DevOps and shift left strategies, the dev team should follow certain principles such as code readability and testability. When codes are developed with a concern for their readability as well as suitability for testing, DevOps and shift left approaches become easier to implement. The developers can make use of element IDs, inline comments and notes, and incorporate aesthetics into their code to improve readability. Adopting the principles of encapsulation and lose coupling is one way to improve testability.
Best practices for shift left testing in DevOps
The whole development lifecycle should be well planned and documented. There should be participation from every team in the planning and discussions and the documentation should cover requirements analysis, project documentation, supporting documentation (Unit/feature level documentation with test cases) as well as inline documentation.
Since testing is pushed to the early stages and there are quality checks across the entire development lifecycle, the need for adopting universal quality standards is very crucial in the left shift approach. However, not every team and team member will be familiar with different quality standards. The QA team should help the other teams by first educating them on common quality standards. They can also create a document to outline various principles and parameters of quality assurance and provide a guideline on how to avoid common mistakes. The document should also help other team members to understand their share of responsibility in terms of testing and quality assurance.
Static analysis or static code analysis is a method of debugging that is performed by examining the code without executing it. The basic code structure is examined thoroughly to ensure that it follows the best coding standards and practices. Static code analysis aims to find programming errors, syntax anomalies, substandard practices, and security issues in the code. Since the process can be tedious, it is better to automate static analysis before pushing it to the QA team. Since automation is involved, chances for false positives are high. So, the QA team should have a basic understanding of the code they are reviewing and should be familiar with various parameters of static code analysis. Proper inline documentation plays a vital role in static analysis.
As stated earlier, both DevOps and shift left strategy encourage team collaboration and participation at multiple levels of the product development lifecycle. Program architects, designers, developers, testers and the operation team should continuously participate in the process and give feedback whenever necessary. The benefit of continuous testing and feedback is that the code modules will be cleaner and error-free when it reaches the next team involved in the lifecycle. As a result, the need for easy fixes and code reworks will be less to nil. Also here, the emphasis is put on shared responsibility.
Ever since the software industry embraced agile and DevOps principles, there was an overwhelming demand for ensuring quality in every stage of the software development lifecycle. The introduction of strategies such as MVP (Minimum Viable Product) and microservices etc. further illustrated the importance of executing testing at earlier stages of the development. The shift left approach is a result of various evolution and improvisation that happened in the software development industry.
Are you looking for pre-vetted DevOps engineers for your next projects? Contact our team of experts for a free consultation.