"project_baseline": [
{
"link": "/documentation/project-administration/new-code-period/",
- "text": "New Code Period"
+ "text": "Defining New Code"
}
],
"project_quality_gate": [
Branch settings and quality profiles are the same as those set for the master branch, and by design, it's not possible to configure other values. The New Code Period is the only exception to this as it can be set on a branch-by-branch basis.
-### New Code Period
+### New Code
-You can set a New Code Period for each branch. This is especially helpful if you are likely to develop and release multiple versions from the branch. See the [New Code Period](/project-administration/new-code-period/) documentation for more information on setting a New Code Period.
+You can set a New Code definition for each branch. This is especially helpful if you are likely to develop and release multiple versions from the branch. See the [Defining New Code](/project-administration/new-code-period/) documentation for more information.
### Quality Gate
SonarQube Scanner uses information from the project's SCM, if available, to:
* Assign a new issue to the person who introduced it. The last committer on the related line of code is considered to be the author of the issue.
-* Estimate the coverage on new code, including added and changed code, on the new code period.
+* Estimate the coverage on New Code, including added and changed code since in your New Code.
* Display the most recent commit on each line the code viewer.
---
-title: Setting Your New Code Period
+title: Defining New Code
url: /project-administration/new-code-period/
---
-By focusing on code that's been added or changed in your New Code Period, you can set consistent quality requirements and expectations on all new code. With this focus, your new code will be issue-free and you'll clean up the code you encounter along the way. For more information on the New Code Period, see the [Clean as You Code](/user-guide/clean-as-you-code/) page.
-You can set a New Code Period at the global, project, or branch level.
+Defining what is considered New Code is an important part of SonarQube's Clean as You Code approach to code quality and safety. By focusing on code that's been added or changed since your New Code definition, you can set consistent quality requirements and expectations. Your New Code will be issue free and you'll clean up the code you encounter along the way. For more information on New Code and why it's important, check out [Clean as You Code](/user-guide/clean-as-you-code/).
-## Setting a global New Code Period
-Your global New Code Period will be the default for your projects. You can set the global New Code Period at [**Administration > Configuration > General Settings > New Code Period**](/#sonarqube-admin#/admin/settings?category=new_code_period/).
+## Setting your New Code definition
-You can set the global New Code Period to the following:
+You can define New Code at the global, project, or branch level.
-* **Previous Version** – The New Code Period defaults to **Previous version** which shows any changes made in your project's current version. This works well for projects with regular versions or releases.
-* **Number of days** – You can specify a number of days for a floating New Code Period. For example, setting **Number of Days** to 30 creates a floating New Code Period beginning 30 days from the current date.
+- **Global level**
+ You can set a global New Code definition at [**Administration > Configuration > General Settings > New Code**](/#sonarqube-admin#/admin/settings?category=new_code_period/). What you define as New Code at the global level will be the default for your projects.
-## Setting a project-level New Code Period
-You can override the global New Code Period by setting a project-level New Code Period from the project page at **Project Settings > New Code Period**. Starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), this will be the default New Code Period for all of the project's branches.
+- **Project level**
+ You can set a New Code definition for your project at **Project Settings > New Code**. What you define as New Code at the project level will be the default for the project's branches if you're using an edition that supports multiple branches (starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)).
-You can set a project's New Code Period to the following:
+- **Branch level**
+ You can define New Code for each branch from the **Actions** column of the branches table on the project's **New Code** settings page if you're using an edition that supports multiple branches (starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)).
-* **Previous Version** – Set the New Code Period to show any changes made in your project's current version. This works well for projects with regular versions or releases.
-* **Number of days** – Specify a number of days for a floating New Code Period. For example, setting **Number of Days** to 30 creates a floating New Code Period beginning 30 days from the current date.
-* **Specific analysis** – Choose a previous analysis as your New Code Period. The New Code Period will show any changes made since that analysis.
+## New Code definitions
- **Note:** For Community Edition, you can set the New Code Period to a specific past analysis at the project-level because Community Edition doesn't support multiple branches. Starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can set the New Code Period to a specific analysis at the branch level. Each branch can be set to one of the branch's specific past analyses. See the following section for information on setting a branch-level New Code Period.
+You can define New Code as changes from a previous version, a specific analysis, a reference branch, or within a specific period (number of days):
-### Setting a branch-level New Code Period
-_Branch analysis is available starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)._
-For projects with multiple branches, you can set a New Code Period for each branch from the **Actions** column of the branches table on the project's **New Code Period** settings page.
+- **Previous Version** – Define New Code as any changes made in your project's current version. This works well for projects with regular versions or releases.
-You can set a branch's New Code Period to the following:
+ Available at the global, project, and branch level.
-* **Previous Version** – Set the New Code Period to show any changes made in your branch's current version. This works well for branches with regular versions.
-* **Number of days** – Specify a number of days for a floating New Code Period. For example, setting **Number of Days** to 30 creates a floating New Code Period beginning 30 days from the current date.
-* **Specific analysis** – Choose a specific past analysis of the branch as the New Code Period. The New Code Period will show any changes made since that analysis.
+- **Specific analysis** – Choose a previous analysis as your New Code definition. Any changes made since that analysis are considered New Code.
+
+ Available at the branch level starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and the project level for community edition.
+
+[[info]]
+| For Community Edition, past analysis is available at the project-level because Community Edition doesn't support multiple branches. Starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can do this at the branch level, and each branch can be set to one of the branch's specific past analyses.
+
+- **Reference Branch** – Choose a specific branch to define your New Code. Any changes made from your reference branch are considered New Code.
+
+ Available at the project and branch level.
+
+- **Number of days** – Specify a number of days for a floating New Code period. For example, setting **Number of Days** to 30 creates a floating New Code period beginning 30 days from the current date.
+ Available at the global, project, and branch level.
## Focus on New Code
-With Clean as You Code, your focus is always on New Code (code that has been added or changed in your New Code Period) and making sure the code you write today is clean and safe.
+With Clean as You Code, your focus is always on New Code (code that has been added or changed according to your New Code definition) and making sure the code you write today is clean and safe.
-The New Code Period can be set at different levels (global, project, and starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) at the branch level). Depending on the level at which your New Code Period is set, you can change the starting point of your New Code Period to fit your situation.
+The New Code definition can be set at different levels (global, project, and starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) at the branch level). Depending on the level at which your New Code definition is set, you can change the starting point to fit your situation.
-For more information on the New Code Period and setting it, check out [Setting Your New Code Period](/project-administration/new-code-period/).
+For more information on setting your New Code definition, check out [Defining New Code](/project-administration/new-code-period/).
## Personal Responsibility
Your Quality Gate is a set of conditions that tells you whether or not your project is ready for release. With the Clean as You Code approach, your Quality Gate should:
-* **Focus on New Code metrics** – When your Quality Gate is set to focus on New Code metrics (like the built-in Sonar way Quality Gate), new features will be delivered cleanly. As long as your Quality gate is green, your releases will continue to improve.
-* **Set and enforce high standards** – When standards are set and enforced on New Code, you aren't worried about having to meet those standards in old code and having to clean up someone else's code. You can take pride in meeting high standards on _your_ code. If a project doesn't meet these high standards, it won't pass the Quality Gate, and it's obviously not ready to be released.
+- **Focus on New Code metrics** – When your Quality Gate is set to focus on New Code metrics (like the built-in Sonar way Quality Gate), new features will be delivered cleanly. As long as your Quality gate is green, your releases will continue to improve.
+- **Set and enforce high standards** – When standards are set and enforced on New Code, you aren't worried about having to meet those standards in old code and having to clean up someone else's code. You can take pride in meeting high standards on _your_ code. If a project doesn't meet these high standards, it won't pass the Quality Gate, and it's obviously not ready to be released.
For more information on Quality Gates and making sure your Quality Gate is enforcing your standards, check out the [Quality Gates](/user-guide/quality-gates/) documentation.
## Pull Request Analysis
-You can use Pull Request analysis and decoration to make sure your code is meeting your standards before you merge. Pull Request analysis lets you see your Pull Request's Quality Gate in the SonarQube UI. You can then decorate your Pull Requests with SonarQube issues directly in your ALM's interface.
+You can use Pull Request analysis and decoration to make sure your code is meeting your standards before you merge. Pull Request analysis lets you see your Pull Request's Quality Gate in the SonarQube UI. You can then decorate your Pull Requests with SonarQube issues directly in your ALM's interface.
-For more information on setting up Pull Request analysis and decoration, see the [Pull Request](/analysis/pull-request/) documentation.
\ No newline at end of file
+For more information on setting up Pull Request analysis and decoration, see the [Pull Request](/analysis/pull-request/) documentation.
| Issue | When a piece of code does not comply with a rule, an issue is logged on the **snapshot**. An issue can be logged on a source file or a unit test file. There are 3 types of issue: **Bugs**, **Code Smells** and **Vulnerabilities** |
| Measure | The value of a **metric** for a given file or project at a given time. For example, 125 lines of code on class MyClass or density of duplicated lines of 30.5% on project myProject |
| Metric | A type of measurement. Metrics can have varying values, or **measures**, over time. Examples: number of lines of code, complexity, etc. A metric may be either _qualitative_ (gives a quality indication on the component, E.G. density of duplicated lines, line coverage by tests, etc.) or _quantitative_ (does not give a quality indication on the component, E.G. number of lines of code, complexity, etc.) |
-| New Code Period | The period for which you're keeping a close watch on the introduction of new problems in the code. Ideally this is since the `previous_version`, but if you don't use a Maven-like versioning scheme you may need to set a relatively arbitrary time period such as 21 days or since a specific date. |
+| New Code definition | A changeset or period that you're keeping a close watch on for the introduction of new problems in the code. Ideally this is since the `previous_version`, but if you don't use a Maven-like versioning scheme you may need to set a time period such as 21 days, since a specific anaylsis, or use a reference branch. |
| Quality Profile | A set of **rules**. Each **snapshot** is based on a single quality profile. See also [Quality Profiles](/instance-administration/quality-profiles/) |
| Rule | A coding standard or practice which should be followed. Not complying with coding rules leads to **Bugs**, **Vulnerabilities**, **Security Hotspots**, and **Code Smells**. Rules can check quality on code files or unit tests. |
| Remediation Cost | The estimated time required to fix Vulnerability and Reliability Issues. |
* When the analyzer has just been upgraded (because rule implementations could be smarter now)
* When the rule is external
-As a consequence, it is possible that backdating will keep newly raised issues out of the New Code Period.
+As a consequence, it is possible that backdating will keep newly raised issues out of New Code.
## Automatic Issue Assignment
---
## Issues
**New issues** (`new_violations`)
-Number of issues raised for the first time in the New Code period.
+Number of issues raised for the first time on New Code.
**New xxx issues** (`new_xxx_violations`)
-Number of issues of the specified severity raised for the first time in the New Code period, where xxx is one of: `blocker`, `critical`, `major`, `minor`, `info`.
+Number of issues of the specified severity raised for the first time on New Code, where xxx is one of: `blocker`, `critical`, `major`, `minor`, `info`.
**Issues** (`violations`)
Total count of issues in all states.
Total count of Code Smell issues.
**New Code Smells** (`new_code_smells`)
-Total count of Code Smell issues raised for the first time in the New Code period.
+Total count of Code Smell issues raised for the first time on New Code.
**Maintainability Rating** (`sqale_rating`)
(Formerly the SQALE rating.)
Effort to fix all Code Smells. The measure is stored in minutes in the database. An 8-hour day is assumed when values are shown in days.
**Technical Debt on New Code** (`new_technical_debt`)
-Effort to fix all Code Smells raised for the first time in the New Code period.
+Effort to fix all Code Smells raised for the first time on New Code.
**Technical Debt Ratio** (`sqale_debt_ratio`)
Ratio between the cost to develop the software and the cost to fix it. The Technical Debt Ratio formula is:
The value of the cost to develop a line of code is 0.06 days.
**Technical Debt Ratio on New Code** (`new_sqale_debt_ratio`)
-Ratio between the cost to develop the code changed in the New Code period and the cost of the issues linked to it.
+Ratio between the cost to develop the code changed on New Code and the cost of the issues linked to it.
---
## Quality Gates
Effort to fix all bug issues. The measure is stored in minutes in the DB. An 8-hour day is assumed when values are shown in days.
**Reliability remediation effort on new code** (`new_reliability_remediation_effort`)
-Same as _Reliability remediation effort_ but on the code changed in the New Code period.
+Same as _Reliability remediation effort_ but on the code changed on New Code.
---
## Security
Effort to fix all vulnerability issues. The measure is stored in minutes in the DB. An 8-hour day is assumed when values are shown in days.
**Security remediation effort on new code** (`new_security_remediation_effort`)
-Same as _Security remediation effort_ but on the code changed in the New Code period.
+Same as _Security remediation effort_ but on the code changed on New Code.
**Security Hotspots** (`security_hotspots`)
Number of Security Hotspots
**Security Hotspots on new code** (`new_security_hotspots`)
-Number of new Security Hotspots in the New Code Period.
+Number of new Security Hotspots on New Code.
**Security Review Rating** (`security_review_rating`)
**Security Review Rating on new code** (`new_security_review_rating`)
-Security Review Rating for the New Code Period.
+Security Review Rating for New Code.
**Security Hotspots Reviewed** (`security_hotspots_reviewed`)
**New Security Hotspots Reviewed**
-Percentage of Reviewed Security Hotspots (Fixed or Safe) for the New Code Period.
+Percentage of Reviewed Security Hotspots (Fixed or Safe) on New Code.
---
## Size
The Project Hompepage is the entry point of any project showing:
* the releasability status of the project
* the current state of its quality
-* the quality of what has been produced since the beginning of its [New Code Period](/user-guide/clean-as-you-code/).
+* the quality of what has been produced since the start of the [New Code](/user-guide/clean-as-you-code/).
The Project Page answers two questions:
If not, details and drill-downs are immediately available to quickly identify what went wrong, with a section for each error condition showing what the current project value is and what it should be. As usual, you'll be able to click through on current values to get to drilldowns.
## What should I fix first?
-Because the best way to improve a project's quality is to catch and fix new problems before they become entrenched, the first view of a project is centered around the New Code Period, which is highlighted in yellow on the right of the project homepage. The project space page shows a high-level summary of critical metrics, both current values and their New Code Period values.
+Because the best way to improve a project's quality is to catch and fix new problems before they become entrenched, the first view of a project is centered around New Code, which is highlighted in yellow on the right of the project homepage. The project space page shows a high-level summary of critical metrics, both current values and their New Code values.
Just below the Quality Gate information, you have the numbers of old and new Issues in the Reliability and Security domains and then the Maintainability domain. Clicking on any figure on the page will take you to a detailed view, either in the Measures Page or the Issues Page.
### How can I see all the issues in a project?
The project-level **Issues** menu item takes you to a project-specific Issues page, where you can perform all the same actions you can at the higher level.
-On this page, you can easily narrow the list to the New Issues introduced during the New Code Period, by selecting `New Code` in **Creation Date** facet.
+On this page, you can easily narrow the list to the New Issues as set by your New Code definition, by selecting `New Code` in **Creation Date** facet.
### How can I see the project structure and code?
The project-level **Code** menu item takes you to an outline of your project structure. Drill down to see files in a directory, and choose a file to see its code.
projects / sonarqube.git / commitdiff