Deploying a solution from the development environment to production environment.

Replies to This Discussion

Permalink Reply by Garrett Dieckmann on January 18, 2017 at 2:10pm

Kelly,

Did you find a deployment process that you liked, or hear of a best practice for deployment?

We're just starting to use NeuronESB, and the process I've been using has been to use Git source control for versioning the solution folder (excluding a couple of the configuration files, and the history) in the development environment. My plan is to use some of Git's features to perform the deployment to Production.

The main issue that I've encountered so far is that some of our 'code' and 'configuration' are in the same files. For example, I want to version the XML file for a Process that I have created. That Process contains both code and configuration. The code can be moved without a problem, but I also have a 'Table Query' Process Step that contains a Connection String specific to my Test environment and that is not valid for Production. My plan is to document those types of issues, and manually update those types of items post-deploy. It's fine now, with just a small handful of places that need updating, but I really need to find a better solution when we setup more endpoints and processes...

Thanks for any info about your experiences,

Garrett

• ▶ Reply

Permalink Reply by Christian Stærk on January 24, 2017 at 4:38am

Garrett, you should probably take a look at environment variables. They are created for storing configuration that differers between environments (or Deployment Groups). Except in special cases, there should be no need to patch anything post-deploy.

Now, the Table Queury process might actually be an exception like that. I do not think you can bind any properties to environment variables or set related message properties.

The SQL Adapter is deprecated, so in your scenario, I would use an .Net ODBC adapter endpoint and bind the connection string property to an environment variable. And then call this directly from your process.

Then you are able to do a simple XCopy from GIT, given that you have configured development and test servers to use different deployment groups.

Hope this helps,

Christian

• ▶ Reply

Permalink Reply by Christian Stærk on January 24, 2017 at 5:02am

Hi Kelly

It is pretty much what we are doing at several clients. 

All the environment are set to use different deployment groups and then we use environment variables to store all configuration that differs (connection string, access control listes, API keys etc.)

Basically we then do a full XCopy with some additional backup of the existing files. We automated it using PowerShell and then have a single .zip file that moves between environments (Test, QA, PreProduction, Production). This ensures that it is the exact same code base being tested.

(there are some additional steps, when updating the runtime and I have outlined it here: https://www.integrator.dk/2014/05/fully-automated-neuron-esb-install/ ).

I would advise against doing partial deploys or patching. That only opens up for all kinds of errors.

We usually use source control to get a list of changed artefacts since last release. This also determines the amount of regression test that we need. I do not think you can avoid doing some sort of regression testing, but usually it is not that hard automating much of it in unit tests and so forth.

Hope that helps.

Christian

• ▶ Reply