Shift-left means moving things early to the left in the development pipeline instead of running them at the end. This typically refers to the tests as we already learned that testing late in the pipeline leads to many problems. We often neglect tests at the end because of a lack of time or resources, or we do only basic tests and ignore edge cases. What’s worse, even if we find issues, it’s very expensive to fix them because we already finished the implementation and pushed it through most of the pipeline.
To avoid these issues, we want to test early and more often. This is what shift-left refers to. Instead of testing applications just before the release, we want to test our applications early to identify issues when it’s still easy to fix them. However, shifting to the left carries much bigger consequences. Let’s see what.
Shift-left and ownership
Shifting things to the left leads to more ownership. Testing requires understanding and being able to reason about things we test. Developers can’t test something they don’t understand. They also can’t test things they don’t have access to. Therefore, developers need to build an understanding and working knowledge of the systems they work on.
This leads to much bigger changes. Specifically for databases, developers need to understand how databases work and how to improve their performance. This makes it easy for developers to take ownership of the databases and work on them end-to-end.
Developers need to have tools that let them work with databases on their own. They need tools that can show database state, meaningful database-oriented metrics, or insights about database internals. These tools need to integrate with developers’ environments, CI/CD pipelines, IDEs, and other developer tools. Developers need to have tools that let them build and maintain databases the same way they build and maintain their applications.
Shift-left is an ownership.
Communication and Collaboration
Shift-left leads to a reduction in communication. Developers need to own their databases and be able to work on every database-related aspect like performance or schema optimization. Developers need to be responsible for everything in the database world, from the very first deployment to the last day of maintenance.
Recommended reading: How To Master PostgreSQL Performance Like Never Before
To do that, developers need to work efficiently. We know that the biggest killer of efficiency is communication. Opening tickets to other teams, sharing logs, asking for help, explaining problems, or having meetings takes time and slows things down. We need to reduce communication as much as possible. Effectively, we need to bring teams together and ultimately merge them to avoid the cost of communication. This is exactly what happened with DevOps culture in the last decade.
Developers need to have tools and processes that let them see how databases perform. Developers need to access metrics, logs, performance indicators, history, and configurations. All of that needs to be developer-friendly and integrate with developers’ environments. They need to use these tools within their teams.
Shift-left reduces communication and increases close collaboration.
Shift-left and self-servicing
Last but not least, shift-left requires self-servicing. Developers can’t wait for other teams to provide input or respond manually. Everything needs to be automated and controlled directly by developers. They need to be able to unblock themselves with automated solutions and self-servicing platforms that don’t require manual intervention from other teams.
This is a must-have for the whole industry. We can’t keep the manual solutions, registration forms, onboarding spreadsheets, and other forms that need to be processed manually. Everything needs to be automated. This way developers can configure and optimize their databases on their own which increases velocity and decreases MTTR.
Shift-left requires automation and self-servicing.
Summary
If you want to stay on top of the DevOps movement, you need to take a shift left to the extreme. You need to let your developers own their databases, self-service their issues, and work within their teams to reduce communication. You need to have tools that integrate with developers’ environments, IDEs, and CI/CD pipelines. This is a tremendous cultural change for developers, databases, and your whole organization. Metis helps you drive this change. Talk to us to learn more.
