You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the path towards automation, the idea of the runbook is to slowly swap out individual steps / methods in the class for automated actions, eventually cutting out the humans entirely. To facilitate this we need the concept of an automated step, one which does not prompt but performs an action and logs it.
Considerations include acceptance criteria, whether the user should confirm the action or just let it happen, repeatability, etc. Also right now the methods are invoked to return dynamic doc strings, so this behavior might be in conflict if the method has to run.
Some possible implementations:
def_deploy_cf_stack():
passdefdeploy_cf_stack(action='_deploy_cf_stack'):
""" Deploys the CloudFormation stack with parameters derived from the previous steps. """
defdeploy_cf_stack(auto=True):
""" Deploys the CloudFormation stack with parameters derived from the previous steps. """defaction_fn():
self.helper.deployStack()
returnStepInfo(description="dynamic docs!", action=action_fn)
defdeploy_cf_stack(with_action):
""" Deploys the CloudFormation stack with parameters derived from the previous steps. """defaction_fn():
self.helper.deployStack()
with_action(action_fn)
return"dynamic docs"
defdeploy_cf_stack(action):
""" Deploys the CloudFormation stack with parameters derived from the previous steps. """@actiondefdo_deploy():
self.helper.deployStack()
return"dynamic docs"
The text was updated successfully, but these errors were encountered:
I've just recently discovered this repo, after experimenting with the Ruby runbook implementation out of braintree. Having the ability to easily mix manual and automated steps is a key feature for us and I'm wondering if you'd consider an implementation where the method simply IS the automated implementation when auto=True. I think this would be very intuitive and make it about as simple as possible to add in automated steps, keeping runbooks pretty clean. The downside is that you would loose support for dynamic doc generation, but I didn't totally follow the use case around that and how important that is. Here's what it would look like, given your examples above:
def deploy_cf_stack(auto=True):
"""
Deploys the CloudFormation stack with parameters
derived from the previous steps.
"""
self.helper.deployStack()
With all this said, if the dynamic doc feature is important (or if I'm missing something else), then I'd vote for the 2nd option you posted above, which is fairly similar. It adds more required boilerplate to turn on the automation, which can add up and potentially take away from runbook readability, but perhaps a reasonable trade off. In our use case, I'm not anticipating using the dynamic doc feature.
def deploy_cf_stack(auto=True):
"""
Deploys the CloudFormation stack with parameters
derived from the previous steps.
"""
def action_fn():
self.helper.deployStack()
return StepInfo(description="dynamic docs!", action=action_fn)
In the path towards automation, the idea of the runbook is to slowly swap out individual steps / methods in the class for automated actions, eventually cutting out the humans entirely. To facilitate this we need the concept of an automated step, one which does not prompt but performs an action and logs it.
Considerations include acceptance criteria, whether the user should confirm the action or just let it happen, repeatability, etc. Also right now the methods are invoked to return dynamic doc strings, so this behavior might be in conflict if the method has to run.
Some possible implementations:
The text was updated successfully, but these errors were encountered: