Feature: Run a Deployment sub-step

[arm4b]

Currently, BitOps glues several steps into a single monolithic pipeline.
According to feedback, BitOps should allow a controlled run of a specific sub-step of the deployment.

This will be helpful in debugging, developing, or even trying to re-run the specific step in the middle of the failed pipeline without triggering the entire workflow which is time-consuming.

With the deployment workflow including terraform, helm, and ansible, the tool should be able to provide a CLI endpoint to run only specific step like ansible.
Ideas:

bitops run ansible <...options>
bitops deploy ansible <...options>
bitops ansible <...options>

TODO

• Implementation
  • CLI endpoint
• Testing
• Documentation

[arm4b]

Consider ENV variables for the implementation/interface (deploy only this tool).

[mickmcgrath13]

something like:

SKIP_DEPLOYMENT_TOOLS="terraform, ansible, helm"

also should provide a single tool to overwrite other tool deployments

DEPOLOY_ONLY="terraform, helm"

comma separated lists to define which tools should be used or ignored.

Note: should find better names for these :)

[mickmcgrath13]

I wonder if we could just have a simple block after this to the effect of:

if env. DEPLOY_ONLY:
  bitops_deployment_configuration = bitops_deployment_configuration.filter(env. DEPOLOY_ONLY)
else if env. SKIP_DEPLOYMENT_TOOLS:
  bitops_deployment_configuration = bitops_deployment_configuration.filter(!env. SKIP_DEPLOYMENT_TOOLS)

[arm4b]

To me, ENV-only approach reminds of feedback that was highlighted before: "Too many ENV variables, and they're confusing".

As a user, there should be an easier way to do things instead of managing a wall of ENV vars passed to the BitOps container. CLI would add to intuitiveness, while ENV might be a second-grade option to do the same action.

[mickmcgrath13]

yeah, I agree a cli tool would be better. It's also a much higher LOE (level of effort).

the env var approach would be a way to provide the functionality with relatively low LOE.

side note: I personally don't mind a wall of env vars. If you're using tools like this in checked-in pipelines (as we all should be..), you rarely have to think about them. Perhaps we could present the env vars in a better format (something we have another issue for already).

[arm4b]

With Ops repo generator (init CLI argument entrypoint) #353, here is how it all may come together as a consistent CLI:

Proposed in #353 OpsRepo generation:

docker run \ 
-e BITOPS_ENVIRONMENT="test" \
-v $(pwd):/opt/bitops_deployment \
bitovi/bitops init

Deploy all:

docker run \ 
-e BITOPS_ENVIRONMENT="test" \
-v $(pwd):/opt/bitops_deployment \
bitovi/bitops deploy
# old way for backward compatibility:
# bitovi/bitops

Proposed here Deploy Terraform only step:

docker run \ 
-e BITOPS_ENVIRONMENT="test" \
-v $(pwd):/opt/bitops_deployment \
bitovi/bitops deploy terraform

Proposed here Deploy Terraform and Ansible steps:

docker run \ 
-e BITOPS_ENVIRONMENT="test" \
-v $(pwd):/opt/bitops_deployment \
bitovi/bitops deploy terraform ansible
# alternative separator:
# bitovi/bitops deploy terraform,ansible