Installer Workflow

Component: Sql Persistence
NuGet Package NServiceBus.Persistence.Sql (1.x)
Target NServiceBus Version: 6.x
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.

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 workflow.

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

Samples

Related Articles


Last modified