A Simple, Yet Powerful Approach to Clean Code!

Hi everyone, I'm Clint Cameron, Product Marketing Manager at SolarSource. And today I'm going to demonstrate how easy it is to code smarter and harness the power of clean code in your DevOps workflows. Now let me first start with a traditional workflow and show how it can waste a tremendous amount of developer time. Code is written and pushed to the main branch. Auditors flag potential issues and then devs return to the code to triage and separate real issues from false positives. The end result is that up to 42% of developer time can be spent on rework and remediating bad code. At SolarSource, we have a better way to app development, a clean code approach. We put the developer in charge of the code quality and give them the tools to write only clean code. It's inefficient to push issues to your main branch or a feature branch only to revisit those issues later. Instead, let's find those issues as soon as they occur and eliminate them from even getting committed in the first place. Okay, we can see that the clean code approach is more efficient. What exactly does that mean for you and your team? Well, direct ownership of the code by the developer and the team. It means efficient and maintainable code. Code that's robust and reliable when executed. It means, of course, code that's safe for your users and for your organization. And then finally, code that fosters innovation and keeps developers happy. Okay, in a minute, I'm going to demonstrate how you can add clean code to your workflow using SonarCloud and the Sonar solution. It's 100% free for public projects and you can analyze your code in minutes. Now, before I demonstrate, let me quickly walk you through the solution. In my demo, my project is housed in GitHub. We also have a tight integration with Azure, Bitbucket, and GitLab. It all starts with a pull request, which kicks off an auto scan of your code. Now this auto scan can be easily integrated with your existing CI CD system. Now from the analysis, we get back a set of code quality metrics and a clear indication of any issues. The analysis results are automatically synced back to GitHub. So you get valuable insights right where your team lives, eats, and breathes. Now onto the demo. All right, y'all, here's our code for our demonstration. First thing is to go ahead and kick off an analysis in sonarcloud.io. So we'll authenticate using our GitHub credentials. Navigate to create a new organization. That automatically gets pulled over and we'll import that. We're going to go ahead and select a free plan and get that project pulled in. And that's it. Sonarcloud will take care of the rest. It's going to prep for an analysis and then fully run that analysis. Now depending upon the size of your project, the number of lines of code containing your project, it could take a few minutes for that to run. I only have about seven minutes with y'all. So in the interest of time, let's pause and pick things back up once the analysis is done. All right, analysis completed. Let's take a look at it. We navigate to the main branch and see that we've got some reliability, security, and maintainability issues. And so that's great to get a baseline understanding of what's going on in your main branch. Now other than those vulnerabilities, those should get fixed. But everything else, it's kind of watering the bridge. What's important is let's start catching things from now. Let's instigate a clean code process from now so that we're shifting left. When things happen, let's catch them as soon as possible and prevent things from ever even getting close to reaching the main branch. Let's catch them before they even reach a feature branch. So to that end, I'd like to do an analysis against the pull request. So I have a branch set up already in GitHub. We'll kick off a new pull request against that. And that's all it takes. That's going to go ahead and kick off automatically and scan our pull request. Just like the main branch, depending upon the size of the pull request, the number of lines of code included, it could take a few seconds, could take a few minutes for the analysis to complete and fully run. So it's running right now. I expect it to finish. There it goes right there. It's finished. Okay. So there, we can see that we have a failed quality gate due to a vulnerability in our pull request. All right. Well, we don't want that. So let me show you something super cool right now. Right here, you can see that if I were to try to merge this pull request, it's red. I click on it. It's blocked. Unless I have administrator privileges. So you can set it up so that if you get a red quality gate on a pull request, no merging unless it is cleaned up. Okay. We'll cancel that. Now, let me go ahead. We're in the conversations tab. Let me take you over to the checks tab. You can see we have a nice integration there as well. And I also want to show you something cool here that is our integration with the code scanning capabilities of GitHub. And you can see there, you get even more information about this vulnerability. And if we go to the bottom here, we can see that it looks like we could have that we have an injection flaw. So if we click on show paths, we can see that we have a source right here in app.js. And we can see it traverses through five different steps, actually crosses over into another file called app handler.js. And that's our sync. The point being that we want to provide as much information in GitHub as possible. It's where you work. So let's get the right information at the right time to you so you can make decisions. And to that end, we have this little quick box here. We can go ahead and triage things as maybe that's a false positive. Maybe it's just used in testing. Or for a reason, we say we're not going to fix that. Okay. Let me finish off by taking you back to the checks tab here and showing you. There we go. One last feature. If I click right here, I can actually then open up this pull request, get those same set of metrics that we saw in the main branch, but now it's against RPR. There's our vulnerability. I can click right there and dig into it a little more and find out exactly. We see that same path here. So we have app.js down to app handler.js with three steps in between. Same information, just a little more ability to dig in deeper and find out exactly what's going on with that vulnerability, as well as some tips to go ahead and correct it, because that's the name of the game. All right. Thank you. Happy clean coding. And we'll talk to you later. See you. Thanks for watching.