Project scope question

Hey guys,
I am trying to implement Octopus at my company.
We tried a few months ago, with a huge super complicated project, which was rapidly changing, little knowledge of octopus, or its capabilities and also key team members breaking their legs, literally.
So anyway, I’ve convinced my team mates its time for another shot!
At the moment, i’m looking at implementing a project to manage an ever growing number of on premise dynamics CRM deployments, each have several sets of solutions, each CRM deployment has a set of configuration variables, which i believe i can build from a single unique identifier for each deployment.
Before i begin, i am being forced to keep the number of projects down, so a top down approach for our default CRM deployment, cloned for each subsequent client CRM deployment, deploying every set of individual variables, might not be feasible. As the number of projects will rapidly skyrocket and the bo$$ cans it.
I want to attempt a breadth approach, deploying each set of solutions across all deployments, automating all backups etc. I’m just worried at this point i might run into some unforeseen roadhump halfway through the project.
I’m wondering if anyone sees any issues with this approach?
My basic strategy per CRM deployment is:
deploy some solutions, build a config file from the unique identifier, apply the config, move onto the next CRM deployment, rinse and repeat
I want to encapsulate this all into a single project, i want to easily be able to add new CRM deployments into this project…

… And then have multiple projects like this.
Am i approaching this in completely the wrong way?

Are there some new features in V3 i’m not aware of yet? I’ve heard rumblings of swapping variable sets in and out of the same project. Would this be the best thing for us rather than what i am attempting?

I appreciate any feedback and can’t wait get int o it, octooopuuuusss! :slight_smile:

Hi Ryan,

Thanks for getting in touch!

I haven’t had much experience with deploying CRM, but I’ll try to help. Correct me if I’m wrong at any point.

If I’m reading correctly, you have a number of solutions (I assume these are solutions that ultimately become a single nuget package that Octopus can use?) and you need to deploy all of these solutions to a number of target servers. In other words, the collection of solutions represents the things you need to deploy to each server. Each target has different configuration files, and you’d want to back up databases each time and probably run some other steps.

In general, it’s a good idea to think of a project as the isolated application you want to deploy (in this case, a CRM instance), and your deployment targets as the instances you want to deploy to. The project has a set of steps that will run on one or more deployment targets. Whether you have one target or 50, the same deployment gets run on each.

If you have components that get deployed in completely different ways, then you’d start looking at different projects, but I’ll assume it’s only the configuration and maybe even the nuget packages that change between CRM instances.

If that’s the case, you’d likely install an Octopus Tentacle on each of the on-premise servers. Each of those would then be a “Machine” in Octopus which would represent a CRM instance that you’d be deploying to. In terms of configuration, you could handle that a number of ways (again, I’m not sure how configuration works with CRM). The ideal way would be using the features that handle Configuration Files. You could either transform a base config file based on variables (these could be scoped to individual machines), or if you wanted to replace the configuration file completely, you could include a script that copied the appropriate config for each machine over the top.

Your project would have steps that would be run on each machine, either one by one or in parallel. Each step runs on each machine, and each time, the values of variables get set based on their scoping - e.g. for the current environment, project, machine, or role. You could even specify the name of the package to deploy based on a scoped variable.

In terms of new features in V3, I don’t think there’s anything new that would affect your scenario. You can set up Variable Sets that apply globally, and reuse them for each project, but that’s nothing new :slight_smile:

I hope that helps, and let me know if I completely got it wrong!

Damo

Hi,

Vanessa also brought to my attention that this sounds a bit like a multi-tenancy arrangement. In which case, we have a few recommendations in our documentation: http://docs.octopusdeploy.com/display/OD/Multi-tenant+deployments

Those may help as well!

Thanks,
Damian Brady

Wow, thanks so much for the swift reply Damian, i’m really sorry but my brain was somewhere else earlier and i mistyped:
"a project to manage an ever growing number of on premise dynamics CRM deployments"
should have been:
"a project to manage an ever growing number of hosted CRM deployments"
They all live in the same place, in a clustered environment :frowning:

As you said:
"(I assume these are solutions that ultimately become a single nuget package that Octopus can use?)" This is correct.
“and you need to deploy all of these solutions to a number of target servers” My bad, they will pretty much all be deployed to the same target, a control server in the CRM environment.
“In general, it’s a good idea to think of a project as the isolated application you want to deploy (in this case, a CRM instance)” All of the CRM instances are connected to several multi tenanted websites (one tenancy per instance), so CRM downtime means site downtime, or might not as the devs are still discussing this. This is why i have been leaning away from this approach.

Sorry, i have to run now, but i really appreciate the post and any help you can give me.
CHeers,
Ryan

Hi Ryan,

Thanks for the reply!

Ok, no problem - it definitely looks like a multi-tenant situation. We nearly have a solution for that - we’re working on it at the moment. In the meantime, the link I posted earlier about multi-tenant deployments in the current version is probably your best bet.

Depending on how many instances there are, you may still want to consider a tentacle for each CRM deployment. They’d physically live on the same server, but they’d act as if they were independent. Adding a new deployment would then involve just configuring a new instance of the Tentacle. You’d have to work out whether this would work for your situation, however.

I hope that helps,
Damo

Thanks Damian, you’ve been a great help and given me plenty to think about, would you say a project developed to deploy to multiple tentacles on the same server would be easily adapted to incorporate new multitenancy features? Or would it require a rebuild?
Cheers,
Ryan

Hi Ryan,

That’s a good question and I can’t really give you a definite answer. However, I’d expect if it’s a single project with multiple tentacles, we’d make it fairly easy to modify. Most likely it would just be similar to moving tentacles between environments - you’d just specify which tenant the tentacle belonged to.

I hope that helps!
Damo