Actions: Let your engineering team delegate toil to the robots

If you want to make software engineering easy to improve, then automate actions in your development process. These simple yet high-impact “if this, then that” conditions pack a punch toward reducing toil and cognitive load. Your developers choose what’s important to improve and reap the benefits of an efficient and optimized development environment.

While guardrails establish boundaries and keep teams safe, and notifications bring team members' attention to critical information so they can take action before it’s too late, actions allow you to do tasks automatically when specified conditions are met — so developers can stay focused on innovation instead of toil.

Actions are at the core of reducing developer toil

In the context of automation, actions refer to the principle of "if this, then that." You’ll recognize it as when a certain condition or state is detected, an action is taken as a result. However, an action stands distinct as it typically leads to a change in the state of a system.

Actions can vary widely. Examples include adding a comment to an issue, transitioning an issue from one state to another, or even modifying a pull request, such as adding a label, merging it, or closing it. An action can trigger an alarm in an incident response platform, automating an immediate response to a certain situation or condition.

The change in the state of a system or an application is at the heart of automation. In essence, we are setting up rules and thresholds for the robots (automations) to follow and trust them to modify the state of another system based on these rules.

Historically, humans have performed actions in response to changing circumstances or thresholds. An operations engineer might monitor graphs and respond to abnormal lines or values, either by taking direct action or by alerting someone else to the issue. With automation, though, we've offloaded many of these tasks to systems that can perform them more consistently and quickly, reducing developer toil.

High-impact results on engineering efficiency

Actions have a profound impact on the way we operate within software development and IT industries. In extreme cases, actions can even automate a role completely, saving considerable time and resources spent on repeatable tasks and keeping human focus on innovation. From preventing costly downtime on a website to simply improving efficiency, the impact of actions can be high or subtle, depending on the context.

Consider a scenario where a developer starts working on a new feature using an issue tracker. The developer clicks a button, which provides a branch name for the new code and changes the task status to 'In Progress'. When the code is pushed to GitHub and a pull request is created, the task automatically changes to 'In Review'. And once the pull request is merged, the task status automatically updates to 'Closed'. This automation reduces the toil and cognitive load for developers significantly, improving efficiency and ensuring that the status of tasks is always up-to-date.

At times, these actions can have a more visible impact. For example, an action can automatically post the link to a staging environment as a comment on an issue, providing access to other people within the organization. This empowers project managers, designers, and stakeholders to self-serve much of what they need, enhancing the visibility of the work being done and making collaborations smoother.

The flexibility of actions and their ability to be tied together with other tools in the ecosystem is where their true potential lies. They allow teams to achieve high-impact results with minimal investment, catering to their specific needs and workflows. The impact of actions can range from critical to mundane, but each one adds to the efficiency and effectiveness of the processes.

Actions in practice

During Bitbucket's early days, the team addressed the noticeable disconnect between pull requests and Jira-tracked issues by creating a custom integration. This integration took the form of an action that added details about pull requests to the relevant issues in Jira, whenever a pull request was deployed.

At the time, the deployment process was a manual and highly custom affair, using Bamboo and a series of server logins, code updates, and service restarts. The integration they developed gave visibility into the relationship between the inception of work (an issue) and the completion of some of that work (a pull request).

Although not revolutionary now, this was a significant milestone in tying the lifecycle of development work together, which became the groundwork for many future integrations in Jira.

Another example comes from using Sleuth. We designed as action to change the state of an issue to "Deployed to Prod" when it was actually deployed in production. It might seem trivial, but this tweak gave a more accurate picture of the work's status and helped in detecting anomalies. If an issue was in the "Done" state but not marked "Deployed to Prod," it raised flags, prompting investigation into why it wasn't deployed. In a sense, this action offered a method of process anomaly detection, which could be incredibly valuable in maintaining an efficient workflow.

Actions tailored to workflows boost the dev experience

Actions are an invaluable tool for developers, allowing them to customize their workflows and processes to their unique needs. Having a solid set of out-of-the-box actions is valuable, but what truly empowers developers is the flexibility to tailor these actions to their own requirements, ensuring that the tools fit the workflow rather than the other way around.

Moreover, most developers have an inherent desire to improve and optimize things – it's in the nature of their job. When given the ability to write software that improves their own workflow, developers are naturally inclined to do so. Actions allow them to scratch this itch in an efficient and effective manner.

What it takes to implement actions

Implementing actions in a developer's workflow can range from straightforward and built-in to complex and potentially challenging. For instance, most issue trackers now have first-class integrations with popular services like GitHub, Bitbucket, Azure, and GitLab, making it easier to implement actions. In fact, some tools are specifically built with these integrations in mind, recognizing the need for these actions and making the process as simple as possible.

However, creating custom actions, such as changing an issue status to "Deployed to Prod" upon deployment, can be more complex without a predefined framework and secure authentication. Developers will need to capture the “if this” event, worry about API interactions with external systems, and deal with API keys and the custom code to perform the action. This process requires substantial initial effort and ongoing maintenance.

While expanding the framework theoretically becomes easier once set up, different actions might necessitate interacting with new APIs, extra variables, or unique system information, complicating the process. With time, the maintenance cost of custom-built actions can add up, making it often more efficient to use existing tools and frameworks that come with maintenance support.

What’s next

If you’re following this series, you’ve read how we at Sleuth are thinking about engineering automation, the critical role of guardrails in codifying ways of working, how smart notifications prevent disasters from crushing developers' flow, and in this article, how automated actions let developers offload toil-inducing tasks – all in the vein of improving engineering efficiency.

Next up: learn how workflows combine all automations into a curated set of services that support engineering teams in the way they want to work.