All ServiceControl deployment options listed below rely on the files produced by packaging. Packaging creates the deployment binaries in the deploy directory. Some of them are packaged into zip files in the zips folder, and other deployment artifacts are built from these pieces.
The zips are packaged as embedded resources in the ServiceControl Management Utility. Although the zips are embedded in a specific assembly, ServiceControl Management ships as a self-contained, single-file executable that contains everything.
When installing an instance, the following binaries are unzipped from the embedded resources and combined to form a complete instance:
- Application and persistence files
- All transport assemblies (not just the selected one)
- All files from
InstanceShared.zipthat are common to all 3 application instances - RavenDB server files (ServiceControl and Audit only)
The installer also generates a configuration file based on:
- User input, defaults, and previous settings
- In some cases, hints from the
transport.manifestorpersistence.manifest, such as config keys that are no longer used
The PowerShell module is built during the release workflow in the deploy/PowerShellModules directory. The release process pushes it to the PowerShell Gallery.
The release workflow builds multi-arch Docker images with a specific version tag and pushes the images to the GitHub Container Registry. The release process distributes the packages to Docker Hub with multiple tags (for example latest, 5, 5.4, and 5.4.0) using the push container images workflow.
Images are available in the following Docker Hub repositories:
The binaries are shipped to the PlatformSample via the Particular.PlatformSample.ServiceControl NuGet package with the transport hard-coded to LearningTransport and the persister hard-coded to RavenDB. To avoid shipping RavenDB binaries twice, the platform sample hosts its own RavenDB.Embedded instance and connects both the ServiceControl and Audit instances to it.