We have a WPF application, Web Services and Windows Services plus a legacy VB6 appication to deploy to regular dev, test and staging environments plus over 70 client test and production environments.
I know that Octopus has a command line octo.exe which can package the VB6 components into the NuGet and can run the installation scripts taking into account the client side variations which is fantastic.
However some of our clients require us to deploy to their test and production environments. Some like us to deploy to their test environments while they deploy to their production environment and the remainder deploy to their test and their production environments.
My question is can Octopus be configured in such a way as to support the above scenario with, and this is the important bit, each client user having zero visibility of our internal environment and more importantly no visibility of the other client environments in the Octopus Web Portal.
I understand Projects and Permissions can restrict what users can “do” but can they also restrict what users can “see”.
Thanks for getting in touch! Octopus has very granular specific permissions that will provide exactly what you need. Just as a test I created a team with access to 1 project, 1 environment and setup roles for only deploying and release creation. You can see in the screenshot that the view of the project hides the process and varaibles settings but shows the dashboard screen and releases - they cannot see outside of their scope.
So this is possible. Have a test - and get it how you need, it will take some management due to the number of custom options you will need, but your customers will not be about to see outside of their scope.
Thanks for your help before xmas. We are now actively setting up a demo environment with 5 clients to test our internal set up before committing our 70 tentacle production environment.
Our senior developer Deepak, has some specific questions and has contacted support but not received an answer. Please can you help him find the answers to our questions?
Our ticketing system can get caught up in spam, have him check there. But below is a copy and paste of the response.
Vanessa
Hi Deepak,
Thanks for getting in touch!
You can add a role like “DB” to your database machine and have a step within your release that executes DB scripts only on machines with the “DB” role.
You can use Powershell to get the assembly version and then assign that value to an Octopus variable using Set-OctopusVariable which you can later on use for any purpose
John, I’m in very similar position and currently setting up our deployments for multi-tenanted app. I’d be quite interested to hear how you have organised your projects/environments/variables and all the rest. Would you mind sharing that?
At the moment I’m thinking about one project with all the deployment steps, but many environments - one environment per tenant. And each environment will get their own connection string variable. And when deploying - deploy to a specific environment. Does this sound sane?
Hi Trailmax, yes very similar to what we are attempting to set up. In addition each environment will have multiple variables such as sql server name, site name, location, install path and these will also be set by octopus at deployment time. We also have some environments with UAT and Prod and some just with Prod. We are planning to set up the UAT & Prod sites with the ability to cross deploy (oneway).
We are currently evaluating a single environment and fixing bugs and it’s looking good at this point. Will let you know more as we progress inc any problems we come up against. Maybe you can share too?
John, thanks for the info. I’m currently setting up our Octopus, and scoping the inter-webs for ideas/best practices. Once we are happy with our set up I plan to do a blog-post to that effect and will post a link here.
Have you reached a satisfactory solution to your large number of environments? We will have well over 100, possibly over 200 environments, plus tons of variables scoped for those environments. The dashboard is going to be unusable with a large number of environments and the horizontal scrolling…
Justin, no, unfortunately I have not came up with anything better than what you describe. But we are building another layer of management on top of Octupus API. Maybe we’ll have more luck with that, but I would not hold your breath
. Now I know it is possible we can start investing time into putting a demo together.