Release Update 03/01/2024
Insights
Introducing a Brand New Landing Page for Insights NX
We are thrilled to introduce the brand-new landing page view for Insights NX. It comes with a number of features to help you with your daily data analysis tasks. The purpose-built analytics landing page is an excellent way to view and consume insights. The new landing page provides immediate access to your team's recent Dashboards. On this page, you can also stay up to date on the latest DORA trends. The mappings, Dashboards, and HummingBird AI Digest screens can all be accessed directly from the landing page.
Previously, the landing page for Insights NX was the Dashboard listing page, from which users would navigate to other pages. For more info, read here.
Ability to auto-populate Filter Tool Names based on the KPIs in the dashboard
You can use dashboard filters to narrow down component results according to specific criteria. When utilizing the filter by tool option, the KPIs added to the dashboard determine which filters are applied. If there is only one KPI for a single tool, the tool name is auto-populated in the KPI name filter. On the other hand, users must choose each KPI from the dropdowns when there are multiple tools with KPIs.
Previously, users had to choose each KPI filter manually by selecting them from dropdown menus. For more info, read here.
Capability to view the date range for deployment list KPI charts
The data points in the Deployment Charts for the Deployment Frequency and Lead Time for Changes KPI provide information about the deployment activity. Instead of providing an exact date for each deployment, the data projection provides a date range over which the deployments occurred. Users can then click on one of the deployment data points to see a list of commits that contributed to that deployment.
Introduced Branch Level Filters for DORA KPI
A branch-based filter for deployment frequency has been introduced for the DORA KPI. Users can retrieve deployment lists for individual branches with the new filter. This is supported, in addition to the existing deployment status level filters for the KPI. Previously, users were able to filter deployments by success or failure. For more info, read here.
SDLC & DevSecOps
Capability to Pass Report File details into Sonarqube Pipelines
Test execution reports specify which tests from your test suite are executed during a build. Users can send their unit test reports to their Sonarqube tool for the Sonar Scan pipeline steps in Opsera. This eliminates the need to specify report file details in Sonar Pipelines' command line scripts.
To accomplish this, users must enable the Use Build Step Resource option and select the build name for which the file path must be added. When the Sonar scan is run, users can view the line coverage percentage and the unit test runs under the Sonar Ratings V2 KPI.
Opsera's proactive vulnerability management strategy: Assessing Token Validations for automatic updates on Vulnerability Severity
Opsera's proactive vulnerability management strategy enables users to anticipate possible threats ahead of time. This is essential for reducing the possibility of data breaches and safeguarding private data.
Following a task scan, Opsera evaluates the API token and assigns a severity for the list of vulnerable commits that are returned. The severity of a secret whose token has expired is automatically assigned as Low, and the severity of a secret whose token is still valid is automatically assigned as Severe. In order to improve the team's ability to react promptly and efficiently, the serious vulnerability can be granted additional priority and access.
The list of secret tokens that are adafruit-api-key, defined-networking-api-token, doppler-api-token and more. To learn about the entire list, read here.
Capability to configure Rover in Opsera’s Jenkins CLI Builds
Users can configure Rover Build in the Pipeline Step when utilizing Jenkins Build Step in Opsera. Adding this to Opsera Pipelines will help to save time and eliminate the need for manual commands.For more info, read here.
New Capabilities for SCM Task Execution Reports
The SCM Task migration summary reports have been enhanced to offer additional context regarding the Migration Object's Count. The downloadable detailed report now includes new columns for viewing the migration count and status of each object. For more info, read here.
Salesforce
Introducing a New Task to Perform Code Analysis for a Git Branch.
Opsera introduces a Salesforce Branch Code Scan task that allows users to scan their entire Git branch and check its Quality Gates status. This will significantly improve your code quality, security, and branch performance.
As you create the task, you can specify which code analyzer tool and quality gates should be used in the analysis. A detailed summary of the task will be provided by Opsera in the form of charts or tables, which will include the rule name, threshold, pass status, scan engine, and other information. Users can also share the entire execution report by exporting it as a CSV file. To learn more, read here.
Capability to expand and collapsible sidebars in Salesforce diff editors.
Opsera’s Salesforce tasks diff editors have a redesigned user interface that includes a collapsible model and an expanded sidebar. By using this feature, users can make more room for viewing conflicting content by hiding the navigation menu when not in use. This enhances the user experience by making it simple to navigate between different Salesforce components, especially on smaller screens with constrained space.
Additionally, in an expanded view, users can quickly search for and identify a specific file using the newly introduced search bar. Previously, the sidebar on the diff editor was not dynamic.
Ability for Users Without Jira Permissions to Update Package XML for Jira Integration
Opsera allows users to run Jira integration for Salesforce Tasks even if they do not have read/write permission to Jira. Previously, if a user did not have permission to read the Jira ticket associated with the Salesforce task, the task would fail.
The ability to update package XML into Jira ticket is based on the policy set by the user in Opsera's User Policies for Enforce Salesforce Repository Rules.
Last updated

