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!