ServicePulse

ServicePulse provides real-time production monitoring for distributed applications. It monitors the health of a system's endpoints, detects processing errors, sends failed messages for reprocessing, and ensures the specific environment's needs are met, all in one consolidated dashboard.

ServicePulse is part of the Particular Service Platform, which includes NServiceBus and tools to build, monitor, and debug distributed systems.

See the ServicePulse documentation for more information.

Setting up the project for development

Setting up ServiceControl Main and ServiceControl Monitoring instances

ServicePulse mainly presents data provided by ServiceControl and ServiceControl Monitoring instances.

The URLs for both services can be set in src/Frontend/public/js/app.constants.js.

Setting up package managers

ServicePulse uses npm and Bower as package managers. For the solution to work, dependencies must be downloaded before launching the ServicePulse website.

Install dependencies

Install the following dependencies if you don't have them installed yet.

• Git for Windows
• Node.js
  • NOTE: It is good practice when installing or updating node.js on your local environment also to check and make sure that the node.js version for the ci.yml and release.yml workflows match the version of your local environment. Look for the step name: Set up Node.js

Set development environment

Step 0 - Using a suitable IDE for frontend development

Even though Visual Studio or Rider seem to be adequate IDEs for front-end development, they tend to be unreliable with the latest front-end frameworks, linting, and formatting. Because of that, we have extra recommendations to help you succeed even more at front-end development.

Step 1 - run the Vue.js development server

Navigate to ServicePulse\src\Frontend and:

• run npm install to install all the npm dependencies
• run the following command npm run dev (this will host a dev server on port 5173 and start watching for changes in /Frontend directory)

If npm run dev fails with an error related to git submodules not being correctly configured, run the npm install command again to ensure all required dependencies are available, and then run npm run dev.

Step 2 - open the browser

After doing the above steps, navigate to the URL presented by the execution of the Vue.js application to see the ServicePulse application.

Running automated tests

The frontend automated tests utilize Vitest as the testing framework and testing-library for testing utilities. Vitest provide two modes: watch mode in the development environment and run mode in the CI environment by default. Watch mode instantly re-runs relevant tests upon file save, providing immediate feedback during development.

Before running test, ensure you've set up the development server. Navigate to ServicePulse\src\Frontend and run npm install to install all the npm dependencies.

Running component tests

Navigate to ServicePulse\src\Frontend and run:

npm run test:component

This command runs all the component test files *.spcs.ts in the directory ServicePulse\src\Frontend\src and its subdirectories. With watch mode enabled it allows for efficient test development, as only the relevant tests are re-run on file save.

Running application tests

Navigate to ServicePulse\src\Frontend and run:

npm run test:application

Similar to component tests, this command runs all the application test files *.spcs.ts in the directory ServicePulse\src\Frontend\test and its subdirectories.

Running test coverage

Navigate to ServicePulse\src\Frontend and run:

npm run test:coverage

This command generates a report indicating the percentage of statements, branches, function, and lines covered by tests. Additionally, it identifies uncovered line numbers.

Provided npm scripts

Vue.js

• dev - runs vite that starts the development server doing hot reload over source files
• build - runs build script that outputs files to ..\app folder
• lint - checks with eslint all vue, ts, and js files
• type-check - runs TypeScript in no emit mode

Vitest

• test:application - runs all the application tests located in the Frontend/test folder.
• test:component - runs tests all the component tests located in the Frontend/src folder and any subdirectories.
• test:coverage - runs the test coverage report on the files defined in vitest.config.ts

Running from ServicePulse.Host.exe

It is possible to run ServicePulse directly via ServicePulse.Host.exe.

Step 1 - reserve URL ACL

ServicePulse.Host.exe depends on a self-hosted web server. A URL ACL reservation must be set up before the project can run. Either run Visual Studio with Administrative privileges or run the following command to add the required URL ACL reservation:

add urlacl url=URL

Where URL is the configured URL on the local machine.

Step 2 - build ServicePulse site

Execute the build script from the command line:

PowerShell -File .\build.ps1

Note

It might be necessary to change the PowerShell execution policy using Set-ExecutionPolicy Unrestricted -scope UserPolicy

Step 3 - run ServicePulse.Host.exe

Build and run the ServicePulse.Host project in the IDE.

Supported browser versions

ServicePulse is supported on the following desktop browser versions:

• Chrome latest major version
• Edge with EdgeHTML v17+
• Firefox ESR current version
• Safari latest major version

Docker image deployment

Dockerfiles for ServicePulse resides within the src folder. There are 2 docker files:

• 1 for a Windows image
• 1 for a Linux image

Building & staging docker images

The docker files are all built as part of the release workflow, pushed to the Docker hub, and tagged with the version of ServicePulse being deployed. More details are available in the documentation.

For example, If we were deploying version 1.30.1 of ServicePulse, the build configurations after the Deploy step will build the following 2 containers for ServicePulse and tag them 1.30.1:

• particular/servicepulse:1.30.1
• particular/servicepule-windows:1.30.1

These images are tagged with the specific version of ServicePulse being built and pushed to the corresponding public particular/servicepulse{-os} repositories. At this point, the docker images are considered staged. If someone is watching the feed directly, they can install the staged images by explicitly specifying the exact tag, e.g., docker pull particular/servicepulse:1.30.1.

Promoting docker images to production

When a ServicePulse release is promoted to production, one of the steps is to take the staged images and re-tag them as the following:

• particular/servicepulse:1.30.1 => particular/servicepulse:1
  • This is so that customers interested in updates within a major can install the specific major only and not worry about breaking changes between major versions being automatically rolled out. Useful for auto-upgrading containers in a production environment.
• particular/servicepulse:1.30.1 => particular/servicepulse:latest
  • Primarily for developers wanting to use the latest version (docker-compose up -d --build --force-recreate --renew-anon-volumes
  • This is only true if the release's major version is the same as the current latest major version.
    • If a fix is being backported to a previous major, then the :latest tag will not be updated.
    • If a release targets the current latest major or is a new major after the previous latest, then the :latest tag is updated to match the version being released.

Once the tagging has been completed, the images are considered to be publicly released.