New Feature: Trigger Nodes and Source Context hero graphic

New Feature: Trigger Nodes and Source Context

Sep 29, 2023 by Randall Abele

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.

  1. The system which triggered the deployment to start
  2. The person who initiated the trigger
  3. The type of trigger

Common trigger types include the following:

  1. pull_request
  2. push
  3. workflow_dispatch
  4. Armory CLI deploy

In some scenarios, additional details will be present in the trigger node.

  1. Source context for the artifacts involved in the deployment plan
  2. 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.

  1. Pull request title
  2. Pull request number
  3. Actor (person who triggered the deployment)
  4. Source and target branch
  5. Commit SHA (most recent from the PR, or that which maps to push)
  6. Repository
  7. 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.


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

Share this post:

Recently Published Posts

Lambda Deployment is now supported by Armory CD-as-a-Service

Nov 28, 2023

Armory simplifies serverless deployment: Armory Continuous Deployment-as-a-Service extends its robust deployment capabilities to AWS Lambda.

Read more

Continuous Deployments meet Continuous Communication

Sep 7, 2023

Automation and the SDLC Automating the software development life cycle has been one of the highest priorities for teams since development became a profession. We know that automation can cut down on burnout and increase efficiency, giving back time to ourselves and our teams to dig in and bust out innovative ideas. If it’s not […]

Read more

Happy 7th Birthday, Armory!

Aug 21, 2023

Happy 7th birthday, Armory! Today we’re celebrating Armory’s 7th birthday. The parenting/startups analogy is somewhat overused but timely as many families (at least in the US) are sending their kids back to school this week. They say that parenting doesn’t get easier with age – the challenges simply change as children grow, undoubtedly true for […]

Read more