At the heart of software engineering, what every software company is trying to master is, to take a code change and release it to production, as fast as possible, with quality. The catch is what happens in the middle between the code change and the release to production.
What stage do they occur at? Close to the code vs close to the release?
How often do they happen? During validation checks for every PR or once a week for many PRs together?
How fast do they happen? How fast the checks running – in few minutes or few hours?
This will determine how productive your engineers are, how production ready your changes are and how happy your customers are.
Ten years ago, it was normal to release to production once every 6 months, but now with technology, the cloud and evolving practices in software engineering like monolith to micro services and micro-frontends, every change could go to production independently.
But how do you make it happen? How can you reduce the frequency of releases from releasing monthly to releasing weekly, to releasing daily to releasing every time there is a code-change?
The answer is to ensure the checks and balances are close to the code vs close to the release, which means running these at the branch level or the PR level. These checks and balances could be unit, lint, security, performance, visual, regression, API tests, browser-based tests, running close to the code, than to the right side of the pipeline. This results in faster feedback cycles and when the branch is merged, the change is already production ready.
Shift Left is not just about running tests at the PR level, it could further go left, means scrutinizing the design, api specs, architecture, and customer requirements as early as possible, even before they become part of the code base.
Shift Left is also not limited to a particular type of application, it could also be applied to web apps, micro-front ends, monolith apps, micro-services and include AI/ML model pipelines as well.
First, establish your current pain points based on how things are now, then explore and calculate the value you will get if you follow shift left.
This will help you establish the return on investment, which you can then use to convince the team and management why it is important to implement shift left and estimate which area or areas you need to invest in as well as determine how much it will cost. It is imperative, that the cost be a fraction of the amount you are trying to save.
The chart above shows how the cost of fixes increases as the defects are found late in the SDLC- Source NIST (National Institute of Standards and Technology)
Main Pipeline – Cost per Defect at different stages
Shift Left Pipeline – Cost per Defect at different stages
Some points that would help you with the above calculations and investment areas are:
Shift Left Pipeline – Cost per Defect at different stages
Some points that would help you with the above calculations and investment areas are:
Once you answer these, you will be able to better understand where your team/organization currently is, what and where you can improve, the ROI and what you will have to do to get there.
1. If your team had 1000 PR in a year, Shift Left could save you 4 hours per Pull Request which would mean the productivity saving would be equal to 2 engineers working an entire year for free.
2. If you had $500,000 USD revenue loss in production, you could prevent future revenue losses by spending 10% of that which would result in millions of dollars in savings.
Introduction of GitHub Actions and similar tools like GitLab CI and Azure DevOps are some examples of tools, that allow Shift Left to be implemented right in your code repo itself, without having to use another tool.
Besides tools, implementing Shift Left requires a change in mind set. Engage with individuals in different teams who you think will be interested and show them the problem statement, solution and the benefits and ask for their feedback so you can collaborate with them to implement the solution.
1. Invest in automation. Automation is repeatable, consistent, fast and help any organisation move faster compared to manual testing.
2. Automation execution time is normally the slowest factor in any CI/CD pipeline, which increases the feedback cycle time, especially for UI automation. Key to reducing the duration time from hours to minutes is to find a solution that is scalable and at the same time cost effective. DigyKube BYOC, which is a browser farm with these characteristics, removes any limitation of concurrent UI automation execution and reduce UI automation execution to minutes, supporting FAIL FAST, FAIL OFTEN and RUN FAST concepts of CI.
3. DigyKube BYOC also provides a built in comprehensive dashboard to drastically reduce the test failure analysis time. This would be a one stop shop to see automation execution (API, UI, Mobile, Cross Browser SaaS) in once place for your entire organisation.
4. The overall feedback cycle time can be further reduced by running all the verification and validations steps/jobs concurrently. Running unit, lint, lighthouse, accessibility testing concurrently via Github Actions/Digy360 Pipeline jobs for example.
This can reduce the lead time from commit to production phenomenally.
DigyKube BYOC in Shift Left Pipeline
1. Invest in adopting best practices of writing unit test every time a new code is written and increase the coverage.
2. Automation results cannot be relied upon if its flaky and not trustworthy. Invest in stubbing / mocking solution so that automation will be stable and reduce flakiness to a greater extent.
3. Have proper API based test automation and contract testing as well
4. Each automated test must be atomic, independently runnable, small, and stable.
5. Digy4 360 Pipeline supports fully integrated seamless API, UI, Mobile Web, Native App tests automation along with test management and reporting dashboard.
6. Digy4 Test Data for Automation solution would also help increasing the reliability of the automation by using a fully integrated TDA solution.
1. Implementing Fail Fast, Fail Often and Run Fast is important. All three 0f these things tie to your organisation’s ability to run tests super-fast. If you have slow running test suites, you cannot fail fast, you can only fail slow and if you fail slow, then you cannot fail often. Fundamentally if you could run tests concurrently, all three of these become possible.
2. Implement processes on how PRs should be labelled, to reflect the state (ready for review, ready to deploy, etc) , code review mechanism, rebasing PR and other settings, making use of draft PR, branch protection settings.
3. Evangelize these practices and make sure everyone on the team follows the same processes and no one is left behind.
4. Digy360 solution can help here with the Digy Automation Framework.
1. Start with something basic like containerized app running on Github Actions worker node, then move to Kind (Kubernetes in Docker) and move to proper container orchestration platform like K8s for branch level deployment.
2. Deploying code, either to production, the test environment or Shift Left, should follow the same approach and use the same technology to be at parity.
3. Use cost effective solutions like using SPOT instance for Shift Left to keep the overall cost down.
4. For each branch deployment, the deployed app should be accessible via a url like https://pr-1088-app-name.us-west.test.company.com/ so all validation steps of a particular branch can hit this URL to run the tests.
1. Integrate the end-to-end Shift Left infrastructure from the Project Management to Test Management to version control to continuous integration to test execution to continuous delivery and all the way to reporting. This is where Digy360 Pipeline would come in handy which provides a seamless integration end to end.
Digy4 helps you implement Shift Left, as part of its 360 Cloud Testing Pipeline, a comprehensive integrated solution, using its products such as DigyKube BYOC, DigyKube Dashboard, Digy Cloud Runner and integrating them with test management tools, project management systems, version control systems.
Regardless of what state of maturity your team or organisation is in, Digy4 can help you get started with Continuous Integration and helm you move to Shift Left.
If you use Continuous Integration tool like Github Actions or Jenkins as an example, by creating different workflows in Github Actions which listens to various events like PR merge, commit, for different types of verifications and validations steps like unit test, UI automation, accessibility test, visual regression, lint, you can control these steps to be run for every commit in a branch or on demand based on a predefined comment string or other events. For example, if you want to run UI automation against your app every time a code is committed to a branch, DigyKube Github Action workflow can create a browser farm with 100 chrome browsers for example, execute your hundred tests concurrently, finish them in few minutes and call another Github Actions to destroy the browser farm and give the resources back to the cloud provider. The artifacts of each of the runs are captured in a database and help you visualize the results via DigyKube Dashboard. Same applies to API, Mobile Web, Native Apps and Hybrid tests, which can be run, and Digy4 Cloud Runner could collect the meta data so the results can be viewed via the same DigyKube dashboard. Digy360 is tool agnostic, it can work with any CI tool, be it Github Actions, Jenkins or anything else.
Customers are the epicentre. There are hundreds of thousands of options available for customers to get from online every day, be it retail, travel or any e-commerce web platform. The catch here is, what they actually need is in hundreds not thousands or hundreds of thousands. If you want to be near the customer all the time, you have to go fast, you have to focus on quality and repeat the process. Are you ready to Shift Left with Digy4?