Targeted Deployment for Releases

wculler

Based on my observations, I think I already know the answer to this, but I was looking for more clarification and possibly some ideas on how ReadyRoll could do the following.

The problem that we run into is that everywhere I have worked so far, we don't necessarily deploy a release in order. For example:

I decided to try out ReadyRoll as our solution for CI/CD.

I have everything setup for projects in VS through ReadyRoll, auto TeamCity builds at checkin to SVN and Octopus Deploy to push to DEV after a build. This works great.

Let's say that I make targeted changes to some tables/procs for a specific release, 1 for this example, and check them in. Those go through to DEV as designed.

Let's say that I make targeted changes to some other tables/procs for another release, 2 for this example, and check them in. Those also go through to DEV as expected.

Now if we need to push release 2 through to QA before release 1, the changes from release 1 and release 2 go through to QA even though we aren't ready for them. This kind of deployment happens all the time in the environments I have worked in and I can't imagine I'm the only one that works in an environment like this.

Is this something that ReadyRoll can handle that I have just not setup correctly? Any ideas on how this might be done with ReadyRoll?

dnlnln

Thank you for your question and your interest in ReadyRoll.

Managing multiple concurrent streams of development work is a complex subject enough by itself, and the persistent nature of data storage only adds an extra layer of complexity to the picture. In general, we recommend isolating database changes so that they are tested in their own environments, prior to being promoted to the Production environment.

To take your example, I'd start by creating a branch in source control for each set of changes that you intend to promote individually to QA and PROD. I'd also recommend use of the semantic versioning feature in ReadyRoll, which ensures that the correct order of deployment is preserved when those branches are later merged together. This gets over the initial hurdle of ensuring that separate streams of work can be released independently of one another; when it's time to promote to QA/PROD, you just need to pick the release number that contains the relevant changes, and only those will be deployed up the chain of environments.

This leaves the issue of having multiple streams of work being mixed together in the one DEV environment. Technically this is feasible with ReadyRoll, as its incremental deployment style allows multiple sets of changes to co-exist within a single environment (assuming that the changes do not overlap one another and the Programmable Objects feature is not used).

However to avoid the scenario in which one set of changes affects the testing outcomes of another, we recommend scaling out the DEV environments to provide isolation to the deployment and testing of individual change sets. Start by creating separate DEV environments, each one allocated to an individual stream of concurrent work, i.e. DEV1, DEV2, DEV3. Then, configure your TeamCity builds to create the Octopus releases, routing the deployment to the DEV environment that has been allocated to the changeset. Moving to isolated DEV environments not only makes it easier to promote changes up the environment chain (as you only need to pick the environment, not sift through the individual releases), but it also introduces greater certainty that the release that worked in DEV will also work in QA/PROD.

I hope this helps! Please let me know if you have any questions or feedback.

wculler

Thanks for the info Daniel. Let me mull this over and I'll most likely give some feedback in the near future.

wculler

Thanks again Daniel. We decided to move to Git and use feature branches. We're going to try to enforce no overlapping changes and keep a single DEV environment for now. This is working how I wanted it now. I did want to mention something. Since we had to disable programmable objects for this, I tried adding those to the offline schema objects, but I cannot get the UserDefinedFunction entry to pull our functions into the folder in the project.

dnlnln

My pleasure, I'm glad that could be of assistance! Please keep us posted with how well (or otherwise) this approach works for you and you team.

Regarding the issue with functions, I've managed to reproduce the issue you reported. Would you mind trying Function as the entry name (i.e. instead of UserDefinedFunction) and seeing if that resolves the issue?

If so I'll report this to the team so that it can be resolved in the documentation and project template file.

Many thanks!

wculler

Thanks Daniel. I did try Function before posting. I should have mentioned that. That doesn't work either. Even StoredProcedure was a bit finicky and I had to try it several times and move it around in the list to get it imported.

dnlnln

I'm sorry to hear that didn't work. Would you mind checking that your sqlproj entry looks like this?

<SyncToOfflineSchemaModelObjectTypes>Table;Assembly;Contract;Default;EventNotification;FullTextCatalog;FullTextStoplist;MessageType;PartitionFunction;PartitionScheme;Queue;ServiceBinding;Role;Route;Rule;Schema;SearchPropertyList;Service;Sequence;Synonym;User;UserDefinedType;XmlSchemaCollection;StoredProcedure;Function;View;Trigger;DdlTrigger</SyncToOfflineSchemaModelObjectTypes>

Note that you may need to restart Visual Studio after making the change, as well as refresh the ReadyRoll tool-window, for the objects to be populated in the Schema-Model folder.

wculler

Interesting. I could have sworn I restarted Visual Studio after trying Function. In any event, that worked. Thanks Daniel.