Installer Workflow

Component: Sql Persistence | Nuget: NServiceBus.Persistence.Sql (Version: 2-pre)
Target NServiceBus Version: 6.x
This page targets a pre-release version and is subject to change prior to the final release.
Read about SQL Persistence NuGet Packages before proceeding.

Contrasting Workflows

Generally SQL installer script execution at endpoint startup will only be desired on a developers machine.

So the code to enable this would be something similar to.

Edit
endpointConfiguration.EnableInstallers();
var persistence = endpointConfiguration.UsePersistence<SqlPersistence>();
var isDevelopment = Environment.GetEnvironmentVariable("IsDevelopment") == "true";
if (!isDevelopment)
{
    persistence.DisableInstaller();
}

In this manner a developers machine can be identified by the existence of the IsDevelopement environment variable. A development machine could also be identified by checking a machine name convention, command line argument or any other toggle based on the specific environment.

Development Workflow

A standard development work operates as follows:

  1. Build Project.
  2. NServiceBus.Persistence.Sql.MsBuild creates scripts in bin\Debug\NServiceBus.Persistence.Sql.
  3. Solution is started in Visual Studio.
  4. Endpoint starts.
  5. Toggle is checked and identified as a development machine.
  6. SQL installer script are executed and the required persistence tables are created.

Higher Environment Workflow

The workflow in higher environment may differ based on the specifics of an organizations process. As such the below is a possible work.

  1. Build Project.
  2. NServiceBus.Persistence.Sql.MsBuild creates scripts in bin\Debug\NServiceBus.Persistence.Sql.
  3. SQL installer scripts are copied to a deployment package along with the output assemblies.
  4. SQL installer scripts are reviewed by a DBA or QA team and approved.
  5. SQL installer scripts are executed in higher environment.
  6. Endpoint is deployed and started.

Samples


Last modified