Octopus as a target feedback (internal)

[mcasperson]

Read the RFC (internal link)

We want your feedback to determine if this feature is a good fit for Octopus. Specifically we would like to know:

• Is the idea of Octopus automating itself or other Octopus instances valuable?
• Will these proposed steps solve problems you have seen customers encountering?
• Would the concept of "Octopus as a target" (once rounded out with additional similar steps) be valuable for your teams in terms of sales, marketing, or solutions?

[ryangribble]

Broadly speaking I think being able to have steps that run in Octopus that DO things to Octopus (or another Octopus) are good for some use cases, but im not sure that the use cases mentioned in this RFC are the ones that jump out to me as the ones that it makes sense to solve in this way

Some items mentioned here are no brainers - we absolutely should be able to run a runbook from a deployment process and run a deployment from a runbook, relyng on community step templates to do things like that isnt something we should continue doing (though it also doesnt require "octopus as a target" to have those). Rather than release creation, deployment and approval steps/tasks, I feel that steps that can help create the items inside octopus such as environments, tenants, certificates, accounts, variables etc are where my mind goes when considering "Octopus as a target"... I could see these marrying up well with writing runbooks or deployments that help to create or promote these things from external inputs or one octopus instance to another.

i cant quite follow some of the examples in how these suggested steps would work in practice. For example a deployment step that can deploy a list of projects but has to have the projects and version number ranges typed into it, has to be created in advance of actually wanting to do those deployments etc. im not sure if thats eliminating some of the problems around the brittle nature of dealing with lots of things at scale or the chance of making a mistake. Compared to our existing "voltron project" approach where you have a more first class ability to choose which versions of child projects should be deployed, but has various current scaling problems and limitations (eg 50 projects means adding 50 steps... and it deals with specific versions rather than version ranges). But we could enhance THIS existing feature to allow the parent project to have a list of child projects that will each be deployed (so just add 50 items to a list rather than have to add 50 "deploy a release" steps), and to support version ranges (defined on the release of parent project, for each child) rather than specifically picking a hard set child version.... Yet another piece of the puzzle could be to add workflow concepts to runbook/deployment processes involving looping and other constructs, to make it possible to "run these steps for each project in this list" rather than having to copy out N number of steps for each project.

If the goal is to help people create releases, deploy, approve large numbers of projects, we could provide native UI capability that lets them group projects together (or select them based on comparing 2 environments), shows them what is available to deploy, lets them flter/sort/select with bulk actions which ones to be processed then proceed to actioning them, seeing any interventions, multi selecting those to approve in one action, etc...

There is also a lot of overlap here with what something like the Workato integration/connector we recently shipped can do... it can now write workflows that "drive octopus" plus it contains workflow concepts like looping branching failure paths etc... AND it can incorporate other tooling outside of octopus in those same workflows. In some ways if the goal is to automate a multi project multi deployment complicated release process, it likely involves other tools/processes and not JUST driving octopus, so something like workato might make more sense to be the driver 🤷

I guess all in all, to me, it doesnt necessarily seem like we need to head down the inception road of "driving octopus with octopus" to get around some of these stated problems, so im not sure if this is a solution to that problem or a solution to some other problem 🤔

[mcasperson]

@ryangribble I'm not all that familiar with the "voltron project" approach. Is there something you can link to that describes this?

[BobJWalker]

Voltron Project: otherwise known as a project per component: https://octopus.com/blog/release-management-with-octopus

The original idea came from our doco: https://octopus.com/docs/projects/coordinating-multiple-projects/deploy-release-step

[mcasperson]

Ah, yes. Actually this idea was largely inspired by the step template in that post. If I was reading between the lines correctly @BobJWalker , your script was looking to move away from the ridged process of a Deploy a release step that selects a single child release version and more towards the ability to deploy the latest release (i.e. a floating version, optionally within a range) in in a given environment?

That is what these new steps were proposing, in that they replicate button clicks rather (like "click the deploy button for the Test environment") rather than working with fixed release versions.

[BobJWalker]

It supports quite a bit more use cases than that, but if you got down to it, that is the core piece of functionality.

[mcasperson]

Maybe a better way to frame this proposal is:

1. Create a dedicated Octopus target that captures the URL and API key
2. Create first class steps for the functionality in @BobJWalker step template
3. Point the new steps at the Octopus target
4. Future work then carries the idea across to new resources (i.e. steps to create/update certificates, variables, tenants etc).

[BobJWalker]

I agree with @ryangribble, being able to trigger a deployment or run a runbook shouldn't be in the community library. The steps I wrote are needlessly complex due to the fact it has to interact with the API. If Octopus as a Target only solved for that, it'd be good.

However, I have a few concerns with the proposed idea. I don't know if it fully solves the other use cases. Let's break them down to how often they will like happen.

• Once a week to once a month:
  • How can I add/update/remove a tenant tag or project to 1000 tenants?
  • How can I add 40 people to a new team when I am not using external authentication?
• Once a quarter to once in a lifetime:
  • How can I add/update/remove a role or environment to 100 targets?
  • How can I convert my 200 projects to use execution containers/new azure app service step/workers?
  • How can I add a new notification step to 200 of my projects?

The concern I have is what is the user experience like? Especially for those tasks that will happen maybe once a quarter or once in the lifetime in the instance. Consider this story:

I am Ryan Phillipi at DealerSocket and my parent company Colvera has made the decision that instead of using Slack we now must use Teams. I need to replace all the Slack notification steps with Teams notification steps. I see Octopus has a new feature called "Octopus as a Target" that can do this work for me. Okay, let me jump in and get configured...oh wow, okay, this is a bit complex. I need to create a runbook to modify Octopus. Hmmm, why do I need to do that, I'm only going to run this once...

I think back to when we proposed getting rid of the script console and replace it with runbooks. Immediate pushback. This is how the conversation went when I proposed it to DTN as a solution.

Me: We are thinking of getting rid of the script console and instead require users to create runbooks for those tasks. DTN:

So many of our users didn't want to create a runbook to perform an operation they only need to do once. My concern is we get the same bit of feedback from our customers regarding Octopus as a Target. They only need to do the task once. They might never use it and instead just do the thing manually because it ends up being faster.

On top of that, it is an odd story to tell our users.

In order to add a project to 1000 tenants you need to create a runbook.

The other concern I have is how will our users test these steps? One of the use cases in the deploy child project step template is the "what if" feature flag. It will allow a person to see everything the step will do up to the point of actually making a POST/PUT/DELETE.

If we limit the scope to deploy a release and run a runbook and maybe certificates, it'll solve those problems. But I don't think it will solve the other use cases in a sustainable, user-friendly way.

I agree with @ryangribble, I'd prefer we spend our time fixing the UI to better support those other use cases.

[mcasperson]

Definitely agree on the "what if" flag. That would be a useful feature.

So it sounds like there is a clear delineation between frequently executed processes, and infrequently executed or once off processes.

I imagine these fall into the frequently executed side, and would benefit from being executed from steps:

• Running runbooks
• Creating releases
• Deploying releases
• Updating certificates (let's encrypted specifically)
• Creating / deleting targets (for things like ephemeral testing environments)

These seem to fall into the infrequent camp, and would benefit from better UI:

• Updating tenants
• Updating environments
• Updating deployment projects
• Updating users and teams
• Updating library variable sets
• Updating existing targets
• Cancelling tasks

[mcasperson]

@BobJWalker how does this sound for a proposal?

• Create a dedicated Octopus target that captures the URL and API key
• Create first class steps for the functionality in @BobJWalker step template
• Point the new steps at the Octopus target
• Future work will be extended to other resources that are frequently updated (certificates, targets)
• Infrequently updated resources are out of scope, and would be best addressed directly by improving the UI

[BobJWalker]

Yes, this is shaping up to be much better. That addresses the original concern I had with the original proposal, we are asking users to solve these tasks:

• Updating tenants
• Updating environments
• Updating deployment projects
• Updating users and teams
• Updating library variable sets
• Updating existing targets
• Cancelling tasks

By each one having to create and manage their own process (opens itself up for errors). And in general, they are going to be 85% the same between each customer (there are only so many ways you can add 1 project to 1000 tenants :grin:).

Whereas by focusing on these tasks for Octopus as a Target:

• Running runbooks
• Creating releases
• Deploying releases
• Updating certificates (let's encrypted specifically)
• Creating / deleting targets (for things like ephemeral testing environments)

We know they will most likely be very unique and each company would have its own process they'd want to customize.

[mcasperson]

I caught up with @ryanrousseau to discuss these pitches, these are the notes:

• Ryan agrees infrequently executed tasks like adding projects to tenants is not best handled with a runbook, because runbooks are too heavy weight.
• A generic script step that used an Octopus target would be valuable for this RFC.
• A “self-referential target” that allowed scripts to be run without first generating API keys would be useful with the script step above.
• We do have customers that already use Octopus to manage other instances (IMO has what they call a “management instance”).
• We recommend customers run two instances of Octopus today as best practice for testing upgrades, so running multiple instances is quite common.
• Release management is a good initial use case.
• Looking forward, advanced customers like IMO may be more common, and could be better supported with steps that upgrade other octopus instances, audit deployments etc. These steps would be a natural progression for Octopus targets.