Add shift left devops guide (#7623)
* add shift-left devops guide * add article to FAQs * Update src/data/guides/devops-shift-left-testing.md --------- Co-authored-by: Kamran Ahmed <kamranahmed.se@gmail.com>pull/7672/head
Dan
3 weeks ago
committed by
GitHub
parent
55c35409e3
commit
1e020de085
3 changed files with 184 additions and 0 deletions
@ -0,0 +1,147 @@ |
||||
--- |
||||
title: 'Why Does DevOps Recommend Shift-Left Testing Principles?' |
||||
description: 'Understand why DevOps emphasizes shift-left testing to boost early bug detection, reduce costs, and improve release cycles.' |
||||
authorId: william |
||||
excludedBySlug: '/devops/shift-left-testing' |
||||
seo: |
||||
title: 'Why Does DevOps Recommend Shift-Left Testing Principles?' |
||||
description: 'Understand why DevOps emphasizes shift-left testing to boost early bug detection, reduce costs, and improve release cycles.' |
||||
ogImageUrl: 'https://assets.roadmap.sh/guest/devops-shift-left-testing-16zah.jpg' |
||||
isNew: true |
||||
type: 'textual' |
||||
date: 2024-11-04 |
||||
sitemap: |
||||
priority: 0.7 |
||||
changefreq: 'weekly' |
||||
tags: |
||||
- 'guide' |
||||
- 'textual-guide' |
||||
- 'guide-sitemap' |
||||
--- |
||||
|
||||
 |
||||
|
||||
Why is there so much debate about testing methodologies if DevOps is about streamlining software delivery? Why do we still encounter approaches like shift-left, shift-right, and even shift-down testing? Shouldn’t there be one universally accepted strategy? |
||||
|
||||
[DevOps](https://roadmap.sh/devops) emphasizes rapid development cycles, continuous integration, and delivery, but your projects or teams may have different needs, goals, or challenges. Factors like the **type of application, infrastructure, team size, legacy systems**, and **release schedules** can lead you to choose different testing strategies. |
||||
|
||||
Despite these varying needs and challenges, DevOps recommends shift-left testing principles because it addresses the core problem of catching issues early. By integrating tests early, issues are resolved quickly before they become more costly and complex to fix. |
||||
|
||||
In this guide, you’ll learn what Shift-Left testing is, its benefits, things to consider, and best practices when implementing it. |
||||
|
||||
## What is Shift-Left testing? |
||||
|
||||
Shift-Left testing is a principle in DevOps that involves incorporating quality assurance and other testing activities **earlier** in the software development lifecycle (SDLC). |
||||
|
||||
Over the years, testing has been somewhat considered an afterthought of the development process. The traditional approach waits for the development cycle to end or at least waits until 50% of the development process is done before testing the application. This approach can be slow, costly, and does not maximize resources because bugs found during the tests can’t be easily fixed during the development cycle. |
||||
|
||||
 |
||||
|
||||
The main idea is to move testing to the **left side** of the development process so that it can happen earlier and more often during the design and development phase. |
||||
|
||||
Shift-Left testing aligns with the DevOps principle of continuous integration and continuous delivery (CI/CD) because automated tests can be written alongside the code and executed as part of the development pipeline. This approach ensures that issues are caught early, developers receive immediate feedback, and overall software quality is improved. |
||||
|
||||
To implement Shift-Left testing, organizations often rely on a variety of automated testing tools. While the choice of tools may vary based on team preference and specific projects, below are some popular tools for performing Shift-Left testing: |
||||
|
||||
- Jenkins |
||||
- Selenium |
||||
- Cucumber |
||||
- SonarCube |
||||
- JMeter |
||||
|
||||
## Benefits of Shift-Left testing in DevOps |
||||
|
||||
Let’s explore some of the reasons why Shift-Left is important in your DevOps processes: |
||||
|
||||
 |
||||
|
||||
1. **Reduced cost**: A goal of every organization is to reduce its *operating expenses* and maximize profit. When Shift-Left testing is factored into your development process, bugs are identified and fixed early, which is far less expensive than when you address them after deployment. This approach saves you both time and resources as reworks are minimal. |
||||
2. **Faster feedback and early detection**: Shift-Left testing provides faster feedback on the quality of your code because you’re testing early in the development process. This means you and your team can catch bugs and detect issues before they escalate. Additionally, it reduces the likelihood of finding and fixing defects later in development or in production. |
||||
3. **Improved quality**: The overall experience of your application becomes more reliable and stable because you'll likely find and fix bugs earlier before they impact your users' experience. |
||||
4. **Faster time to market:** Because defects are reduced and the development process is optimized, you can iterate faster and continuously release software. |
||||
5. **Improved collaboration and continuous learning:** Shift-Left testing follows the DevOps principle of collaboration between developers, testers, and other stakeholders. This means the team has a sense of responsibility and ownership, and they’ll learn more from one another. |
||||
|
||||
Shift-Left testing advocates for testing earlier, moving the focus to the **left side** of the development process. You might wonder if this means testing ends after the design and development stages or if there's something like **right-side** testing as you prepare to go live. |
||||
|
||||
Well, you guessed right, there's indeed Shift-Right testing. Let’s explore that next. |
||||
|
||||
## What is Shift-Right testing? |
||||
|
||||
Shift-Right testing is a principle in DevOps that involves incorporating quality assurance and other testing activities **later** in the software development lifecycle (SDLC). This is usually done when software has been released or is being used in production. |
||||
|
||||
Unlike Shift-Left testing, which occurs at the beginning of the development process, Shift-Right testing occurs after the application has been deployed into production. It involves: |
||||
|
||||
- Closely monitoring the application’s performance in the production environment to identify bugs and issues. |
||||
- Gradually releasing new features to selected users to test their impact first before doing a full rollout. |
||||
- Collecting feedback from users to understand the overall users’ experience and identify areas of continuous improvement. |
||||
- Conducting A/B testing to compare different versions of the software or features to determine users’ behavior and outcomes. |
||||
|
||||
 |
||||
|
||||
The main idea is to move system testing to the **right side** of the development process, ensure that the application performs well in real-world scenarios, and catch issues that may not be apparent during Shift-Left testing. |
||||
|
||||
While Shift-Right testing comes with its own benefits when dealing with production-specific issues, it can be risky. The approach of fixing bugs in production can lead to downtime, cause a negative user experience, and damage your organization’s reputation. |
||||
|
||||
## Challenges in adopting Shift-Left testing |
||||
|
||||
It’s important to understand that Shift-Left testing is not a “magic wand” that solves all your testing problems. It also comes with its own challenges. Below are some challenges you might encounter when adopting it: |
||||
|
||||
1. **Required skills**: Developers, testers, and other stakeholders may need to acquire new skills like test automation, continuous integration, and more. Training can be challenging for teams with limited resources. |
||||
2. **Cultural shift**: Adopting continuous testing on the left side of the development process requires a cultural change for all the stakeholders. Developers may need to take on additional testing responsibilities, while testers may need to acquire new skills. This can lead to resistance, adding to their workload and responsibilities. |
||||
3. **Cost implication**: The implementation process requires new toolsets and automation frameworks, which can be time-consuming and costly to set up. Additionally, teams must overcome the learning curve associated with these tools. |
||||
4. **Integration complexity**: Integrating testing in the early stage of SDLC can be complex, particularly in legacy and large systems. This is because it requires that all team members are aligned and willing to adjust their roles and responsibilities to accommodate the new testing approach. |
||||
5. **Risk management**: Testing early means teams must develop strategies to mitigate the risks associated with early testing and find a balance between early testing and potential risks. |
||||
|
||||
## Overcoming challenges and implementing shift-left testing |
||||
|
||||
Adopting Shift-Left testing in your development process comes with several challenges, particularly related to resources and cultural resistance, which may overshadow the advantages it offers. To successfully implement Shift-Left testing, consider the following strategies: |
||||
|
||||
- **Promote a testing-first mindset** and encourage cross-functional collaboration between your teams with an emphasis on shared ownership of the product. |
||||
- **Invest in training and skill development** focused on test automation, CI/CD, and other DevOps practices. |
||||
- **Choose tools that align with your organization’s needs** and integrate seamlessly within your budget. |
||||
- **Start small** with a feature or pilot project, then gradually scale across the entire product chain. This approach will give your team the flexibility and the time to learn and refine strategies. |
||||
- **Regularly conduct risk assessments** to identify areas for improvement and implement corresponding mitigation strategies. |
||||
|
||||
## Best practices for implementing Shift-Left testing principles |
||||
|
||||
Below are some best practices to consider: |
||||
|
||||
 |
||||
|
||||
1. **Adopt early test plans**: Create a plan that clearly outlines the testing goals and scope of the project. Also, ensure that testing is integrated into the early stages of your SDLC. |
||||
2. **Test automation**: Use test automation tools to automate unit tests, integration tests, functional tests, and other necessary test cases. Additionally, regularly update and maintain test scripts to keep them relevant and accurate when running CI/CD pipeline. |
||||
3. **Collaboration and communication**: Use project management tools like Jira and Linear, along with traditional methods such as meetings, check-ins, and stand-ups, to facilitate communication and collaboration between developers, testers, and other stakeholders. |
||||
4. **Continuous learning**: Encourage your team to keep up-to-date with the latest testing techniques and tools, participate in industry events to learn from experts, and share knowledge and best practices within the team. |
||||
|
||||
## Shift-Left testing in the real world |
||||
|
||||
To gain a better understanding of how teams are using Shift-Left testing to build better applications, let’s explore two real-world examples: Microsoft and Uber. |
||||
|
||||
### Microsoft |
||||
|
||||
Over two and a half years, a Microsoft team successfully replaced 27,000 legacy tests with modern DevOps unit tests and a shift-left process. This approach allowed them to enhance software quality and performance goals. |
||||
|
||||
 |
||||
|
||||
Additionally, the Azure DevOps platform integrates various Shift-Left testing practices, which the team leverages to deliver reliable cloud services and tools to its customers. At the core of Shift-Left testing in Microsoft are: |
||||
|
||||
- Writing tests at the lowest possible level. |
||||
- Writing functional tests that can run anywhere. |
||||
- Treating test code as product code. |
||||
|
||||
### Uber |
||||
|
||||
Uber’s adoption of the Shift-Left testing principle of putting the test at the forefront of its software development process has helped it minimize risk and ensure the reliability and safety of its ride-sharing platform. |
||||
|
||||
 |
||||
|
||||
One major change Uber made was to ensure they could test without deploying to production. This process requires launching a backend integration testing strategy **(BITS)** that enables on-demand continuous deployment and routing to test sandboxes. At the core of BITS are: |
||||
|
||||
- Isolating data between production and test environment. |
||||
- Using [Cadence](https://cadenceworkflow.io/?uclick_id=b36cfaa6-c7d0-4da0-a756-64e7e4c3466e), an open-source workflow engine, to define workflow state, retries, and timers for resource teardown. |
||||
|
||||
## Key takeaways |
||||
|
||||
As businesses evolve, they will bring new challenges and use cases that need to be solved. This means as a DevOps engineer, you need to factor in tests early into the development process to maintain a balance between product quality and speed. Additionally, you need to stay up to date with the latest DevOps trends and toolchains that will help you build reliable applications. |
||||
|
||||
Use the [DevOps roadmap](https://roadmap.sh/devops) to stay up to date with the latest developments and extensions in the DevOps ecosystem. |
||||
@ -0,0 +1,31 @@ |
||||
--- |
||||
import GuideContent from '../../components/Guide/GuideContent.astro'; |
||||
import GuideHeader from '../../components/GuideHeader.astro'; |
||||
import BaseLayout from '../../layouts/BaseLayout.astro'; |
||||
import { getGuideById } from '../../lib/guide'; |
||||
import { getOpenGraphImageUrl } from '../../lib/open-graph'; |
||||
import { replaceVariables } from '../../lib/markdown'; |
||||
|
||||
const guideId = 'devops-shift-left-testing'; |
||||
const guide = await getGuideById(guideId); |
||||
|
||||
const { frontmatter: guideData } = guide!; |
||||
|
||||
const ogImageUrl = |
||||
guideData.seo.ogImageUrl || |
||||
getOpenGraphImageUrl({ |
||||
group: 'guide', |
||||
resourceId: guideId, |
||||
}); |
||||
--- |
||||
|
||||
<BaseLayout |
||||
title={replaceVariables(guideData.seo.title)} |
||||
description={replaceVariables(guideData.seo.description)} |
||||
permalink={guide.frontmatter.excludedBySlug} |
||||
canonicalUrl={guideData.canonicalUrl} |
||||
ogImageUrl={ogImageUrl} |
||||
> |
||||
<GuideHeader guide={guide!} /> |
||||
<GuideContent guide={guide!} /> |
||||
</BaseLayout> |
||||
Loading…
Reference in new issue