This article talks about shifting left as an approach to developing and delivering quality software that is stable on production systems, reducing the risk of a production outage.
DevOps is about continuity; continuous development, continuous testing, continuous deployment, continuous delivery/release, continuous monitoring, and continuous feedback in every stage of software development from ideation to release. This 'continuity' creates a form of a loop, we iterate over the various stages in the software development cycle to improve and ensure things don’t get broken on production and our customers always have quality software/services. DevOps provides a ton of tools and with automation, most of the manual repeatable tasks are reduced, and teams can focus on delivering quality software. How do we ensure things don’t break on production, and our users always have quality service?. Today, IT failures have been inherently accepted and should be expected, most importantly, IT failures should be managed efficiently.
The cost of production outage can not be taken mildly, this can bring a bad reputation to the organization, and possibly the organization may go out of business. How do we ensure that applications competing in a global market do not suffer failure?. The team (developer and operation) needs to be able to identify and solve flaws early in the development and deployment procedures before the software gets to production. There has to be a form of sync, shifting left the operations.
What is Shifting Left:
Shifting Left is a culture, a way of doing software development, where the team is more concerned about being proactive to issues/factors that can cause technical debt at the later stage of the software development lifecycle especially at the production stage. In a shifting left culture, emphasis is on the items that will ensure developers deliver quality code.
Some Areas Engineers can Shift Left
The longer a vulnerability lasts in your SDLC, the more costly it is to fix. Netsparker
System Administrator should ensure the infrastructure or environment created to house the applications are secured and pose no backdoor for vulnerability. To automate this, engineers can use vulnerability scanner tools like Nmap (free and open-source network scanning tool), Microsoft Baseline Security Analyzer(testing Windows systems for vulnerability - MBSA). Application scanning tools like Netsparkercan scan web applications for vulnerabilities. Once vulnerabilities are discovered, it is important that they are eliminated and this process must be tracked for closure.
Developers ensure there are checkers or code reviewers scrutinizing pull requests based on the project coding standard. Set static code analysis and code coverage tools like Sonarcloud, PMD, Jacoco. Sonarcloud is a static and dynamic code analysis tool that generates Bugs, Vulnerabilities, Code smells reports. The team can set a quality gate; acceptance criteria reviews to be used throughout the project. This will enforce quality in the code and make the team follow a standard. It is advised that these standards be set at the early stage of development. However, if you are at the later stage of your project, you could look more at applying the rules on new codes(PRs), and over time you will be introducing fewer bugs to your entire base code. This approach is more manageable than having to start correcting your entire base code after running an analysis.
Developers should be empowered to imbibe the culture of unit testing their codes early in the project. If this is done right, the probability of having little to no technical debt at integrated testing and other testing stages(User Acceptance Testing, Post-Deployment testing) will be high.
Quality Assurance (QA) engineers should perform tests against a verified checklist of items/requirements that the application should meet. Defects detected should be logged and the corresponding remediation is tracked adequately.
However, shifting left seems to be more about testing, finding, and preventing defects early in the software delivery process to reduce/eliminate technical debts and improve the quality of the application. Collaboration and communication among the team(Developers, System administrator/Infrastructure Engineer, QA, etc) must be managed effectively, no one likes re-working but if there is a culture of shared responsibility, then it is a lot easier since the team understands that the goal is to improve the software delivery process and increase the quality of service/software.
To conclude, here is a list of benefits that answers why your team should shift left in their software delivery process.
Automation: removal of human errors, fewer production issues, thus fewer application support tickets raised.
Increased speed of application/service delivery.
Increased revenues: technical debt is removed early and the organization does not need to pay for man-hours that it would have taken to rework any technical debt.
Increased customer satisfaction.
I hope this article was insightful, please share and drop your comments on what your views are on this topic.
Reference
Header Image - Techarcis
Shift Left Testing: What, Why & How To Shift Left
Top comments (0)