Shift Left to Optimize Your Software Development and DevOps Workflows

Welcome to our webinar on Shift Left to improve your DevOps workflows. My name is Puneet Lal.

I'm Laurie Pattison-Gordon. Welcome.

I'm a marketing manager at MathWorks. I have many years of experience in software development, product management, and marketing.

I'm the user experience, customer experience researcher for Polyspace. My role is to help understand your needs and translate them into usable designs. I'm here to give a demonstration of some of our products. Back to you, Puneet.

In this webinar, we plan to cover these items. First, for those who are new to Polyspace, I will give a quick introduction to Polyspace. Next, we will cover the benefits of shifting left. That is benefits of finding bugs early in the development cycle. We'll show you how you can use Polyspace to shift left. Finally, we'll show you how Polyspace can integrate with development processes to provide a complete comprehensive static analysis solution for DevOps and continuous integration.

Let's get started with a quick introduction to Polyspace. Polyspace provides static analysis products that are used by customers to verify that their embedded code is safe. Free of security vulnerabilities and critical runtime errors. And that it complies with industry standards such as ISO 26262 and DO-178.

So, what is static code analysis, and how is it different from unit testing and system testing? Static Code Analysis is a method for code verification that examines source code. Unlike dynamic testing, such as unit and system testing, static analysis does not run the code. You don't have to write test cases or test scripts. Static analysis and dynamic testing complement each other and are essential for producing safe and secure code.

What are the benefits of static analysis? Static analysis products, such as Polyspace can be used to find bugs and to verify that your code conforms to coding standards and naming conventions. Polyspace can generate code metrics such as cyclomatic complexity that can be used to track code quality. Polyspace uses formal methods to prove absence of critical runtime errors and security vulnerabilities under all possible control and data flows. This feature is not available in most other static analysis tools. To learn more about our methods and code proving, please visit MathWorks.com.

Polyspace can simplify certification process and can be used to comply with certification standards.

Let's now quickly look at some of the types of bugs Polyspace can find. Polyspace has hundreds of checkers to find bugs. These checkers are classified in the category shown here. For example, checkers finding division by zero and overflow errors are grouped under numerical. Also listed here are examples of coding standards supported by Polyspace. For example, MISRA and AUTOSAR C++-14.

Polyspace can generate code metrics such as cyclomatic complexity, code density, and stack usage. Here's some examples of runtime errors that Polyspace space can prove that they will never happen. For example, division by zero, buffer overrun, and integer overflow.

This slide shows some of the functional safety standards supported by Polyspace. For example, ISO 26262 for automotive. DO-178 for aerospace. IEC 62304 for medical.

Polyspace has two main types of products. Bug finder products for finding bugs, enforcing coding rules, and generating code metrics and trends. Code prover products for sound and exhaustive analysis that can prove absence of runtime errors. They both support handwritten and generated code. Integrate with Simulink to trace defects back to the model. Provide certification credits, and provide tools for teams to review triage and resolve Polyspace findings.

Let's now shift gears and talk about optimizing DevOps. By optimize, we mean improving efficiency of software development processes. This implies reducing time it takes us to develop, test, and release code. Increasing the quality of code, reducing risk of finding a bug late in development cycle or by a customer, automating code verification to get predictable and repeatable results.

For this webinar, we'll be focusing on code, build, and test stages of DevOps. In practice, these three stages can be further broken down into many steps. For example, let's look at a typical workflow. A developer writes code, runs unit tests, get team members to review the code changes, incorporates review comments, and then checks in the code.

This triggers the build and test process. For the build to be released, it needs to meet the defined quality goals. This picture shows that finding bugs early in the development cycle reduces time and cost of fixing bugs. For a developer, it's much easier to fix a bug when they're still writing the code. They don't need to switch context, and the code is still fresh in their mind. As we move towards the right, more time and resources are needed to find bugs. For example, a bug found after check-in, the developer may have to switch context. Debug the problem, fix, test, and repeat all the processes needed to release the build. It is estimated that up to 70% of projects time is spent on finding bugs, debugging, and testing.

This chart shows that the relative cost of fixing bugs increases exponentially as we move through the development cycle. Hence, it's important to shift left the process of fixing bugs and find them early in the development cycle. We will now show you how Polyspace can help you find bugs as soon as the code is written or modified. Polyspace, as you code, enables you to analyze code without leaving your IDE or editor. You can identify critical defects and security vulnerabilities. You can check for compliance with coding rules standards such as MISRA C, CERT C, and AUTOSAR C++-14. There are plug-ins available for Visual Studio, Video Visual Studio Code, and Eclipse. You can also easily integrate Polyspace as you code with other IDEs and editors using APIs. Now, Laurie will give you a demo of Polyspace as you code.

We begin our tour of Polyspace as you code in the Eclipse IDE. We could have used Visual Studio or Visual Studio Code. We're starting with a file that currently is free from Polyspace Defects. We want to see when we add code if we can keep it this way.

We're going to use a simple example. I add some code here, and I'm going to Run Polyspace as You Code. We can see that the results are pending, and now we see that we have, indeed, three findings.

Clicking on a finding shows more information in the result details. Let's add the equal sign and rerun Polyspace as You Code and see if we've resolved our issue. We're on Polyspace as You Code. And when we see the results, we find that we have indeed resolved this issue.

Let's now look at another file. This legacy file already has 18 findings. We click on this dead code and see we have additional information. And can navigate through the event trace, which will help us travel through the code to the finding. We have additional support by clicking on the question mark. This opens the contextual help. We see some information about dead code, and clicking on the wrench will give us some information about a suggested fix.

However, in this instance, let's say we don't want to fix this issue. However, we do want to remove it from the list. Therefore, we annotate the code by adding a Polyspace comment in the code. We rerun Polyspace, and we should find that this issue no longer shows up in the result list. This is indeed the case.

Now, let's look at how we can control what analysis is done on our code. We go to the configuration. And though we can see there are many settings here related to the build and other items, what we're focused on today is just looking at the check selection. We have a file here that saves the checks that we've selected to run. This file might be one that the company has provided to all users. However, for this sprint, I want to look at just a reduced set of findings. I can do that by looking through the defects or the specific coding standards.

I have some quick links at the top here to select, for example, only advisory, required and such. For now, I'm going to select defects and those that just have a high impact. I will create a new file to save these checks just for my own use. So, here I am. I select high, and I go and save these changes. I'll call these my checkers because it's just for my use now. Later I may revert to what the company has suggested I use.

Let's save these, and we'll rerun Polyspace as You Code and see the difference. Here, I have my 17 findings. However, we'll rerun with this new set of checkers, and we find that when we reduce to just seeing the high impact effects, I simply have one.

Thank you for the demo, Laurie. So far, we have investigated how Polyspace as You Code can improve development efficiency. Now, let's see how Polyspace can provide a static analysis solution for the entire workflow. Polyspace bug finder server and code prover server can easily be integrated into a CI/CD pipeline. These products can find integration issues and prove absence of critical runtime errors and security vulnerabilities. Polyspace findings are uploaded into Polyspace Access. Team members can use a web browser to review triage and resolve these findings.

Next, I will show you a demo of the entire workflow. I'm using a small Azure DevOps project, and we'll be using Visual Studio Code that Polyspace as You Code plug-in. In Visual Studio Code, I'll first pull from the Azure repo to make sure that I have the latest files. Once the pull is completed, I'll create a local branch. Let's call it my changes. And once this branch has been created, I'm ready to add my code. So I had my code, and now I'll run Polyspace as You Code to analyze this file.

Polyspace as You Code has found one issue. It's a simple mistake I made. Let me correct it and rerun Polyspace as You Code. There are no more issues in this file. I'll quickly build this project. And that's clean. So now, I'll check in these changes. I stage my changes and commit my changes to the local branch. Here, I'm adding a comment, and next, I will push these changes to Azure DevOps. The changes have been pushed to Azure DevOps. Let's move to a show.

This is my project in Azure DevOps. So let's look at the repo. we just pushed some changes to it. Looks like the changes made it. Now, let's create a pull request to get these changes reviewed and merged. I will not assign anybody else to this pull request. I'll assign my work item to this pull request and create a pull request. Since I'm the only approver on this pull request, I will approve this pull request and complete the pull request. The pull request will now merge the code to master, and once the merge has been completed, pipeline will be kicked off. And let's look at the pipeline. It's running. Let's look at the job. The build has completed successfully. And it's now running Polyspace server.

The pipeline just completed successfully. Polyspace results have been uploaded to Polyspace access. We'll click the link over here to view the results in Polyspace access. Since this was a very small project, you will see that they are not too many findings. Laurie will now show you a project with more findings.

Let's take a closer look at the access UI. We have a dashboard showing a summary of the results. We have open issues, code metrics, and some details about each type of analysis that has been performed. Here we have runtime checks, defects, and coding standards. We have a trend line here showing the number of open issues over time. In this case, it may have been going up because more and more components have been added to this project. You can close each section. Here we have a detail section that allows us to drill down into the type of defects and see where the concentrations of findings may be.

On the left side, I have folders, which let me know which projects have been uploaded and what result sets I have. We're looking here at example trends, which is an aggregate of all the results listed underneath.

Let's go to a particular Bug Finder example. And here, we only see defects and coding standards. We have another critical item here, quality objectives. We'll look at those in a minute. From here, I may want to drill down into the defects and get further detail. I can do that by clicking here or by selecting one of the dashboards from the dashboard gallery.

Each sub dashboard has the same layout where I have open issues, a trend line, and some details. The details here can be seen by category or by file. This way, I can drill down and see which file or which category of findings have the most results and decide to drill into the review based on this information.

For example, here, let's go over to the result for just this one finding. Similar to what we saw in the Polyspace as You Code UI, I have a result list, I have source code, and I have result details. As we came in from this one finding, we can see in our filter bar that we have filtered to just this one finding. We can remove this filter. Now, we have the fuller result list, the source code, and the findings.

I'm going to click on this finding here in order to be able to show a finding that has an event trace. Just like we saw in Polyspace as You Code. The event trace allows me to travel through the code to the finding. Here though, as this is a collaborative environment, we can take some actions to triage this result. Here, I can change the status of the result. Do we want to investigate, to fix it, justify it? Set the severity. How important do we think fixing this is at this time? How critical is this defect? Assign it to someone, and create a bug tracking ticket.

Often teams will do this triage together. Or different people will do this triage. And others will come in and fix the results coming in from a bug tracking ticket or coming into the dashboard and looking at which results have been assigned to them. Here, we can see I have a result that's assigned to me, and I can click on it and go directly to this result.

The other key thing we want to mention, let's go to a code proper project to do this, is the quality objectives. The quality objectives are really the quality gate. This can be set by a company and customized.

Let's look at the settings. Here, just like we saw in Polyspace as You Code, we have a list of types of checkers. We have defects, runtime checks, global variables, code metrics, and the coding standard checkers and guidelines. I can make a new configuration

And customize what I want to see for the software quality objectives. And then assign this new quality objectives to a particular project. I can view by group, or I can view by category. For example, here, I may want to only select all the high defects for my set of quality objectives. There are six levels here that I can customize, allowing my team to work from one level to the next and to the next.

I could also select MISRA checks and select which ones I want to use across each of these categories. We'll close out of this for now. I can use this software quality objectives as a way to decide what needs to be fixed and what I want to triage first. For example, we can look at all the issues for SQO1. A click into to SQO1, and again, it's in our filter bar. And I see that these are the issues I need to resolve in order to reach this quality level.

As a quick recap, Polyspace access consists of two parts. An overview dashboard, a set of summary dashboards for each check, and a review section allowing you to triage findings quickly and easily. Today we saw the Polyspace as You Code helps you shift left and identify issues while coding on your IDE. This greatly reduces the time to produce quality code. We saw how Polyspace can integrate near DevOps environment and further provide support throughout the development lifecycle.

For this demonstration, we use the Azure platform. Finally, we took a brief look at access UI, which presents findings that are only found later in the cycle. It supports team collaboration and triage. It completes the full development workflow.

You can find more information, of course, on MathWorks.com.

Thank you for attending our webinar. If you have any further questions, please feel free to reach out to any one of us. You can also find additional information and resources on MathWorks.com. Thank you.