DevOps Your Skill: Static Code Quality Analysis
DevOps Your Skill: Static Code Quality Analysis
In this article, we discuss how to add static code quality analysis to your Alexa Skill pipeline and its importance in the day-to-day Alexa Skills development.
Join the DZone community and get the full member experience.Join For Free
Without a doubt, one of the aspects a developer should pay more attention to is trying to always generate understandable, maintainable, and clear code — in short, to generate clean code.
During the development of code (modules, libraries), it is important to integrate objective tools that measure the status of the code and provide the information to know its quality and thus be able to detect and prevent problems: duplicate functions, excessively complex methods, code low quality, non-standard coding style.
These checks are automated in the continuous integration system (CircleCI) and are executed in each new version of the software.
Here you have the technologies used in this project
- ASK CLI - Install and configure ASK CLI.
- CircleCI Account - Sign up here.
- Node.js v10.x.
- Visual Studio Code.
ESLint allows us to automatically fix almost all the rules.
You can install ESLint using npm.
--save-dev is used to save the package for development purposes. Example: unit tests, minification.
Once we have ESLint installed, we have to configure it. With ESLint, you can define your own rules, and in addition, you can also use a set of rules defined by a lot of big companies such as Airbnb, Facebook, or Google. These sets of rules are used by most of the npm packages.
In our case, we are going to use the StrongLoop set of rules from IBM. This package can be installed with the following command:
Now, it is time to configure this set of rules. First, we have to create the file
As you can see, we extend from StrongLoop rules, and we add some extra configurations:
- We set
- In the
envwe set to true the following properties:
nodebecause we are in a Node.js project.
mochadue to the use of this library in our unit tests.
- Finally, I have changed the
max-lenrule setting it to 120 characters instead of 80 defined by
strongloopset of rules.
The last step is to define the
.eslintignore located in the same folder in order to specify the files that we do not want to check their style.
It is something like
Once we have everything configured, we have to set up the reports we are going to use to check our code quality.
The first report we need to set up is the JUnit report. This report will generate a .xml file as output that CircleCI is going to use to print the lint results:
We are going to move one step forward. We want to know a little bit more about our ESLint analysis in every pipeline execution.
This is why we are going to add the
eslint-detailed-reporter npm package to generate a beautiful HTML report with more information rather than the above explained:
This is how this report looks like:
All these reports will be stored in
Now it is time to integrate it into our
package.json to use it in our pipeline with
npm run commands!
So, in this file, we are going to add the following commands in the
script JSON node:
lint: this command will execute the ESLint check and generates the JUnit report:
eslint . --format junit --output-file reports/eslint/eslint.xml
lint-fix: this will automatically fic most of the code style errors_
eslint --fix .
lint-html: this command will execute the HTML report using the npm package explained above:
eslint . -f node_modules/eslint-detailed-reporter/lib/detailed.js -o reports/eslint/report.html
Everything is fully installed, configured, and integrated. Let's add it to our pipeline!
This job will execute the following tasks:
- Restore the code that we have downloaded in the previous step in
npm run lintto execute the ESLint checker.
npm run lint-htmlto execute the ESLint HTML report. It will be executed always, regardless of if the job succeeds or fails.
- Store the JUnit report as CircleCi test artifacts.
- Store the HTML report as an artifact of this job.
- Persist again the code that we will reuse in the next job
- DevOps Wikipedia - Wikipedia reference.
- Official ESLint Documentation - Official ESLint Documentation.
- Official CircleCI Documentation - Official CircleCI Documentation.
The quality of static analysis tools depends on various factors. The main ones are usually efficiency, clarity of your error reports, and a low percentage of false negatives. An advantage of static analysis tools is that they are usually easy to use. many are integrated directly into the IDE and only require the execution of only one simple command as we have seen with ESLint.
That's all folks!
You can find the code in my GitHub.
I hope it will be useful! If you have any doubts or questions, do not hesitate to contact me or put a comment below.
Opinions expressed by DZone contributors are their own.