How Static Analysis Helps You Get Started With DevOps

DevOps requires us to move past simply finding bugs with static analysis. We have to be more proactive and reevaluate the analysis techniques used in the SDLC. DevOps is a collection of practices that facilitate the cross-departmental collaboration and communication necessary to help organizations optimize and accelerate their development processes. Its roots can be traced to the rise of iterative development methodologies that required a different way of operating that blends software development, IT, and QA. DevOps carries with it the potential to remove roadblocks that prevent organizations from meeting modern business challenges.

To be clear, there are no “DevOps tools” that you can purchase and deploy that will suddenly enable you to start “doing DevOps”, but there are necessary mechanisms for implementing a DevOps strategy. In this blog, we’ll discuss how development testing, and more specifically static code analysis, enables organizations to start doing DevOps.

Automated Feedback Loop

The DevOps movement facilitates a partnership between the departments that have an impact on the implementation of requirements. By sharing knowledge and tasks across departments, organizations create an efficient process for accelerating the SDLC while improving quality processes. For DevOps to be effective, however, an automated feedback loop must be implemented that enables the consistent application of quality policies as requirements progress from creation to production.

Most organizations have a feedback loop in place for implementing requirements. At the most basic level, the feedback loop begins with policy and progresses through implementation, measurement, post-mortem, adjust policy, and re-implementation. But in a traditionally operating business, the loop is a cumbersome process executed by siloed departments that often lack adequate knowledge of how upstream or downstream teams operate.

Automation is critical. It is far too costly from a resource perspective for people to stop their normal development and testing tasks to gather data related to the feedback process. Manually producing the feedback loop also risks introducing inconsistent and inaccurate analytics that hamper an organization’s ability to improve development processes and, ultimately, software quality. Organizations can automate the feedback loop by implementing a central point of integration for all the components associated with the development and testing infrastructure. A centralized platform enables BTSs, RMSs, source control, analysis tools, and other components to collect artifacts so that DevOps teams have access to reliable, consistent information that helps them not only prevent defects, but accelerate the entire SDLC.

Development Testing

As the implementation of a requirement progresses, the feedback loop helps developers prevent errors and understand the impact of change as the requirement matures. In terms of doing DevOps, the feedback loop enables the bidirectional flow of analytics from development to deployment and vice versa. Operations contribute to the collaborative process in the form of shaping some aspects of development policy, while development enables the policy to prevent defects that affect operations. This preventative phase of the SDLC is the heavy-lifting process most organizations are familiar with in terms of static code analysis:

1. Determine which static analysis rules to run according to the organization’s development policy according to feedback from operations.
2. Run the analysis and address any defects—again, according to policy.
3. Repeat until the analysis returns an acceptable number of violations.

What’s especially important about this phase from a DevOps perspective is that it involves the ability to capture, measure, and analyze the expediency of the activities performed. Organizations must understand which functions of their quality processes are helping the organization achieve its goals—and which functions are just making noise. This leads into the second phase of development testing for DevOps: the application of a post-analysis analysis to the development policy.

The findings exposed during the preventative phase must be measured, prioritized, and fed back into the development process in the form of an iterated policy. This helps teams that are downstream in terms of implementing the requirement, such as QA and IT, not only do their jobs, but contribute to a continuous process that results in safe, reliable, and responsive code.