1. Общ преглед
В тази статия ще разгледаме статичния анализ на изходния код със SonarQube - която е платформа с отворен код за осигуряване на качеството на кода.
Нека започнем с един основен въпрос - защо първо да анализираме изходния код? Много просто казано, за да се гарантира качество, надеждност и поддръжка през целия живот на проекта; лошо написана кодова база винаги е по-скъпа за поддръжка.
Добре, сега нека започнем, като изтеглите най-новата LTS версия на SonarQube от страницата за изтегляне и настроите нашия локален сървър, както е описано в това ръководство за бързо стартиране.
2. Анализиране на изходния код
Сега, когато сме влезли в системата, ние трябва да създадем маркер, като посочим име - което може да бъде нашето потребителско име или друго име по избор и щракнете върху бутона за генериране.Ще използваме маркера по-късно в момента на анализиране на нашите проекти. Също така трябва да изберем основния език (Java) и технологията за изграждане на проекта (Maven).
Нека дефинираме приставката в pom.xml :
org.sonarsource.scanner.maven sonar-maven-plugin 3.4.0.905 Най-новата версия на приставката е достъпна тук. Сега трябва да изпълним тази команда от корена на директорията на нашия проект, за да я сканираме:
mvn sonar:sonar -Dsonar.host.url=//localhost:9000 -Dsonar.login=the-generated-tokenТрябва да заменим генерирания-маркер с маркера отгоре.
Проектът, който използвахме в тази статия, е достъпен тук.
Посочихме URL адреса на хоста на сървъра SonarQube и данните за вход (генериран маркер) като параметри за приставката Maven.
След изпълнението на командата резултатите ще бъдат достъпни на таблото за управление на проекти - на // localhost: 9000 .
Има и други параметри, които можем да предадем на приставката Maven или дори да зададем от уеб интерфейса; sonar.host. url, sonar.projectKey и sonar.sources са задължителни, докато други не са задължителни.
Други параметри за анализ и техните стойности по подразбиране са тук. Също така имайте предвид, че всеки приставка за език има правила за анализ на съвместим изходен код.
3. Резултат от анализа
След като анализирахме първия си проект, можем да отидем до уеб интерфейса на // localhost: 9000 и да опресним страницата.
Там ще видим резюмето на доклада:
Откритите проблеми могат да бъдат или грешка, уязвимост, мирис на код, покритие или дублиране. Всяка категория има съответния брой издания или процентна стойност.
Освен това проблемите могат да имат едно от петте различни нива на сериозност: блокиращ, критичен, основен, второстепенен и информационен. Точно пред името на проекта има икона, която показва състоянието на Quality Gate - преминало (зелено) или неуспешно (червено).
Кликването върху името на проекта ще ни отведе до специално табло за управление, където можем да изследваме по-подробно проблеми, специфични за проекта.
Можем да видим кода на проекта, дейността и да изпълняваме административни задачи от таблото за управление на проекта - всеки от тях е наличен в отделен раздел.
Въпреки че има глобален раздел Проблеми, раздел „ Проблеми“ на таблото за управление на проекта показва проблеми, специфични само за съответния проект:
Разделът „Проблеми“ винаги показва категорията, нивото на сериозност, етикетите и изчислените усилия (по отношение на времето), необходими за отстраняване на проблем.
От раздела за проблеми е възможно да присвоите проблем на друг потребител, да го коментирате и да промените нивото му на сериозност. Кликването върху самия проблем ще покаже повече подробности за проблема.
Разделът за издания се предлага със сложни филтри вляво. Те са добри за определяне на проблеми. И така, как може да се знае дали кодовата база е достатъчно здрава за внедряване в производството? За това е Качествената порта.
4. Качествена порта SonarQube
В този раздел ще разгледаме ключова характеристика на SonarQube - Качествена порта. Тогава ще видим пример за това как да настроите персонализиран такъв.
4.1. Какво е качествена порта?
Качественият портал е набор от условия, на които трябва да отговаря проектът, преди да може да се класира за продуктова версия. Той отговаря на един въпрос: мога ли да пусна кода си в производство в сегашното му състояние или не?
Осигуряването на качеството на кода на „новия“ код, докато се коригират съществуващите, е един добър начин да се поддържа добра кодова база във времето. Quality Gate улеснява създаването на правила за валидиране на всеки нов код, добавен към кодовата база при последващ анализ.
Условията, зададени в Quality Gate, все още засягат немодифицирани кодови сегменти. Ако успеем да предотвратим възникването на нови проблеми, с течение на времето ще премахнем всички проблеми.
Този подход е сравним с отстраняването на изтичането на вода от източника. Това ни води до определен термин - Период на изтичане. Това е периодът между два анализа / версии на проекта .
Ако повторим анализа, за същия проект, раздела за преглед на таблото за управление на проекта ще покаже резултати за периода на изтичане:
От уеб интерфейса раздела Quality Gates е мястото, където можем да осъществим достъп до всички дефинирани качествени портали. По подразбиране начинът SonarQube е предварително инсталиран със сървъра.
Конфигурацията по подразбиране за SonarQube начин сигнализира кода като неуспешен, ако:
- покритието на нов код е по-малко от 80%
- процентът на дублирани редове в новия код е по-голям от 3
- поддръжката, надеждността или степента на сигурност е по-лоша от A
With this understanding, we can create a custom Quality Gate.
4.2. Adding Custom Quality Gate
First, we need to click on the Quality Gates tab and then click on the Create button which is on the left of the page. We'll need to give it a name – baeldung.
Now we can set the conditions we want:
From the Add Condition drop-down, let's choose Blocker Issues; it'll immediately show up on the list of conditions.
We'll specify is greater than as the Operator, set zero (0) for the Error column and check Over Leak Period column:
Then we'll click on the Add button to effect the changes. Let's add another condition following the same procedure as above.
We'll select issues from the Add Condition drop-downand check Over Leak Period column.
The value of the Operator column will be set to “is less than” and we'll add one (1) as the value for the Error column. This means if the number of issues in the new code added is less than 1, mark the Quality Gate as failed.
I know this doesn't make technical sense but let's use it for learning sake. Don't forget to click the Add button to save the rule.
One final step, we need to attach a project to our custom Quality Gate. We can do so by scrolling down the page to the Projects section.
There we need to click on All and then mark our project of choice. We can as well set it as the default Quality Gate from the top-right corner of the page.
We'll scan the project source code, again, as we did before with Maven command. When that's done, we'll go to the projects tab and refresh.
This time, the project will not meet the Quality Gate criteria and will fail. Why? Because in one of our rules we have specified that, it should fail if there are no new issues.
Let's go back to the Quality Gates tab and change the condition for issues to is greater than. We need to click the update button to effect this change.
A new scan of the source code will pass this time around.
5. Integrating SonarQube into a CI
Making SonarQube part of a Continuous Integration process is possible. This will automatically fail the build if the code analysis did not satisfy the Quality Gate condition.
For us to achieve this, we're going to be using SonarCloud which is the cloud-hosted version of SonaQube server. We can create an account here.
From My Account > Organizations, we can see the organization key, and it will usually be in the form xxxx-github or xxxx-bitbucket.
Also from My Account > Security, we can generate a token as we did in the local instance of the server. Take note of both the token and the organization key for later use.
In this article, we'll be using Travis CI, and we'll create an account here with an existing Github profile. It will load all our projects, and we can flip the switch on any to activate Travis CI on it.
We need to add the token we generated on SonarCloud to Travis environment variables. We can do this by clicking on the project we've activated for CI.
Then, we'll click “More Options” > “Settings” and then scroll down to “Environment Variables”:
We'll add a new entry with the name SONAR_TOKEN and use the token generated, on SonarCloud, as the value. Travis CI will encrypt and hide it from public view:
Finally, we need to add a .travis.yml file to the root of our project with the following content:
language: java sudo: false install: true addons: sonarcloud: organization: "your_organization_key" token: secure: "$SONAR_TOKEN" jdk: - oraclejdk8 script: - mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar cache: directories: - '$HOME/.m2/repository' - '$HOME/.sonar/cache'Не забравяйте да замените ключа на вашата организация с описания по-горе ключ на организацията. Ангажирането на новия код и натискането на Github repo ще задейства изграждането на Travis CI и от своя страна ще активира и сонарното сканиране.
6. Заключение
В този урок разгледахме как да настроим локално сървър SonarQube и как да използваме Quality Gate, за да дефинираме критериите за годност на проект за производствена версия.
Документацията на SonarQube съдържа повече информация за други аспекти на платформата.