The Power of Graphs for Ingesting and Acting on Complex Orchestration Logic
We’ve been having deep conversations with customers and peer thought leaders about the challenges presented by executing multi-environment continuous deployment, and have developed an appreciation for the power of using visual tools such as directed acyclic graphs (DAG) to understand and share the complex orchestration logic involved in multi-environment deployment plans.
This explains why the Deployment Graph is one of the top features in CD-as-a-Service from a customer usage perspective. We were happy to see the feature emerging as a useful touchstone and sought to learn about the nuances of how customers found value in the graph, and to uncover opportunities to build on that experience. As we conducted interviews and prototype iterations together, we learned a lot about how we could lean into DAGs as a powerful visualization of our deployment.yaml plan and the context surrounding it in the holistic software development lifecycle (SDLC).
The high level qualitative insight we heard was that the graph was a very efficient way to understand the plan for a given deployment, and how the execution of that plan went. However, there were certain use cases where gaps in understanding remained, particularly when deployments were in progress, when judgement decisions were required before promotion, or when a prior deployment was being examined for audit or troubleshooting.
Use case 1: What’s this in progress deployment all about?
Customers discussing this use case appreciated the live progress updates for promotions the DAG offered but often expressed confusion about “where this deployment came from”. As we probed that confusion, we found it branched into a variety of detailed questions that revolved around a desire to understand context, either to troubleshoot a problem or to quickly learn about a running deployment from another team.
Paraphrased feedback:
“Who triggered this one?”
“What PR was being deployed here?”
“I’m trying to figure out if the infosec scan ran for this and what the results were”
“Who reviewed the code here?”
Use case 2: Decision time!
Customers who were faced with an approval prompt before promoting to the next environment often had similar questions, but they were asking them for slightly different reasons. When presented with an approval, the thought process was to confirm that I’m the right person to approve and then dig into the details enough to be satisfied that we can move on with the deployment plan.
Paraphrased feedback:
“If I could see the PR here, it would be obvious what I’m approving” “Tracing a deployment back to GitHub so I can check our the PR and approvals is not always simple”
Use case 3: Looking back at the history
What happens when we make updates that other teams are waiting on, internal or external, and no one lets them know it’s available to review or use? Frustration on internal teams, loss of confidence for external users, and software that doesn’t see the light of day if it gets stuck in the process internally due to lack of communication. We use Makelog at Armory to make sure this doesn’t happen.
Unobstructed Change Visibility
One of the biggest challenges that we solved was creating unobstructed change visibility across teams and environments. By connecting CD-as-a-Service and Makelog, we provide visibility into what changes are available in each environment. All of sudden multiple functions (engineers, pms, techwriters, qa) were working together more efficiently, roadblocks were removed, and code moved from staging to production faster. And when code reached production, customers got concise, customer facing communication about the change.
A new node type appears!
A trigger node marks the moment a deployment plan is set in motion. These nodes will always communicate the following information.
- The system which triggered the deployment to start
- The person who initiated the trigger
- The type of trigger
Common trigger types include the following:
- pull_request
- push
- workflow_dispatch
- Armory CLI deploy
In some scenarios, additional details will be present in the trigger node.
- Source context for the artifacts involved in the deployment plan
- Context variables injected at runtime using this process
Source context will be visible if the trigger source is the Armory GitHub Action, and includes the following details.
- Pull request title
- Pull request number
- Actor (person who triggered the deployment)
- Source and target branch
- Commit SHA (most recent from the PR, or that which maps to push)
- Repository
- Tag (when the trigger is a push tag)
Context variables will be visible if any were set at the time the deployment plan was triggered.
Examples
Depending on the type of source control and deployment trigger, different levels of detail will be available as seen in the following examples.
Trigger type: pull_request
Trigger source: Armory GitHub Action
Trigger type: pull_request
Context variables: declared in GitHub Action
Trigger type: push
Trigger source: Armory GitHub Action
Trigger type: push (or push with tag)
Context variables: not declared
Trigger type: workflow_dispatch
Trigger: Armory GitHub Action
Trigger type: workflow_dispatch
Context variables: present, passed through CLI
Trigger type: Armory CLI
Trigger: Armory CLI
Trigger type: deploy
Context variables: none
As these scenarios demonstrate, we were able to quickly enrich the trigger node experience for customers who use the Armory GitHub Action to trigger deployments. That doesn’t mean we’re done though; we are eager to hear feedback about how to improve this feature, and how you like to best apply the unique cognitive power of graphs to the developer platform in your team.
See you out there.
Randall Abele
Product at Armory
