I can’t post to Advice or Knowledge Base so I hope this topic is ok here.
I’ve read most (if not all) the doco on Runbooks and watched the videos.
But I still feel that Runbooks miss the mark a little.
They are there to run against our Infrastructure (deploy targets via environment definitions) and don’t adhere to life cycles.
That’s all fine, but…
- Runbooks aren’t scoped, you need to scope the process step to stop a step running on an specific target.
- So when you Run a runbook definition you are asked for an Environment and you’ll get ALL environments defined for the Space. But it would be nice to restrict the environment list for the runbook. Maybe via the Default Channel’s Lifecycle? (that has to be defined because you can’t delete it)
- If you make a project that only contains runbooks, it would be nice to default to the Runbook section and not the deployment page that says “Define your process”. Maybe have a Setting for default project type. Deployment or Runbook.
- Still runbooks are Ops processes. I’m more interested in seeing what I can run ie. the Runbooks page and not the Overview (list of runs) page.
- Dashboard
- It would be nice to see run buttons on the dashboard, under each environment.
- This would help eliminate the step to choose an “environment”.
- If there are multiple runbook definitions, then a dropdown to choose the runbook would be nice, else just run the first runbook.
- Also the Run button should only show for supported environments. (see the scoping issue)
So why not put my runbooks in my other projects, why use a specific runbook project.
- Mainly to separate/segregate the deployments into production/non production
- Each project then has only the environments it supports show up on the dashboard, overview pages.
- Runbooks can be applied to any/all environments and may not be project specific.
Anyway, Runbooks are good and I’m hoping they become great. 
Hey Tony,
This feedback is very valuable to us, so thank you. And I personally agree with… all of it.
We are going to continue to iterate on runbooks, and this helps guide us.
I’ll try and add a little context on each, and ask a couple of follow up questions if that’s OK…
Runbooks aren’t scoped
We decided early on that it didn’t make sense to restrict runbooks to the same lifecycle progression as the deployment process, and we then wrestled with whether they should be restricted to the same set of environments. We landed on unrestricted as a starting place, but we understand why, even from a usability perspective, it makes sense to want to scope it. I could imagine giving the options to either scope it to the same environments as a lifecycle (via a channel) or just enter the environments directly.
… maybe have a Setting for default project type. Deployment or Runbook.
We discussed exactly this, and like the idea too.
Dashboard …
I’ve read your points on the dashboard a few times. If I summarised them as:
“Optimize more for the scenario where I know which environment I want to execute a runbook against”
Would this be accurate?
Mainly to separate/segregate the deployments into production/non production
Could you explain this point a little further? I don’t understand.
And a couple more questions, if I may
- Who would typically create your runbooks? i.e. developers, operations, etc?
- Who would typically execute them? Is it always the same team that created them?
- What are some of the use-cases you have for runbooks?
Thanks again. Runbooks are a new feature, and feedback like yours helps us make them great.
Hi Michael,
Thank you for replying.
We decided early on that it didn’t make sense to restrict runbooks to the same lifecycle progression as the deployment process
Scoping is nothing to do with progression. Scoping only captures the list of environments from the lifecycle.
“Optimize more for the scenario where I know which environment I want to execute a runbook against”
Would this be accurate?
Yes
Who would typically create your runbooks? i.e. developers, operations, etc?
Much like your video states Runbooks are the Ops in DevOps. So we as devops engineers would typically make them. But with roles I can allow other teams to execute them if that is an appropriate action for them to take. Which I have done with say resetting test IIS servers.
Could you explain this point a little further? I don’t understand.
Regarding project separation.
The great thing about projects and lifecycles been able to restrict deployments to specific environments.
We have a ‘dev’ branch and a ‘master’ branch. ‘dev’ is purely development code and can/should only ever go to a development environment. Now this is exactly what channels provide us and originally when I setup Octopus I had the one project that contained our development packages and production packages utilizing channels to control the separation. Once that project got too big and complex, I moved the development stuff to a development only project and now have separate production/development projects.
This also allows me to have a slightly different deploy process without complicating a single projects deploy process steps with conditionals; such as Only for specific environments etc.
Also now the projects only show their respective deployment environments on the Dashboard, with no mixing of dev/prod environments in the columns.
This is much easier to read and understand at a glance.
So running separate projects allows cleaner separation of target environments.
Runbooks can easily run across any of those environments if we wish. So again a separate project for that makes sense; instead of including them in a specific dev or prod project.
I hope this explains it well enough. If not; them maybe an image may help.
What are some of the use-cases you have for runbooks?
At the moment only simple things like IIS reset of servers.
And updating some additional certificates (not IIS web binding certs, those are using Octopus managed certs)
But I can see many more scenarios becoming available to us soon.
Again thank you for taking the time to reply.
1 Like
