You’ve automated your deployments. Awesome! Maybe you’ve started continuously deploying to one environment or another when changes are pushed to your source code repository. Robots are great, right?
If you have started deploying more frequently as a result of deployment automation, you might find yourself asking some of the following questions from time to time:
What’s awaiting deployment?
When was this bug or performance regression introduced?
How does release cadence influence our teams and projects?
Guess what? So do I. That’s why we record our deployments with a service like Rollbar, Airbrake, or Sentry. Here’s how logging those deployments helps.
What’s awaiting deployment?
Release notes are a challenge to create but are incredibly helpful to identify changes coming. Maybe it’s a QA team wanting to know what changes to expect with the next deploy, or you want to prepare your customers or sales team for what’s coming. In either case, release notes are your answer. By recording the last commit SHA deployed to an environment, you can easily produce a list of commits that are ready for deployment to build release notes.
In addition to other features, services like Rollbar can show what changes have yet to be deployed to a particular environment. With a list of what changes have been made in one environment (release notes) and what changes still need deployed to a new environment, we can prepare teams and customers for changes coming their way and narrow in on any final, manual regression testing.
When was this bug or performance regression introduced?
We love our testing robots, but every so often a bug does make it to production. The question is, what caused it? If it’s truly an error and we’re using Rollbar to capture errors—as we should be—then it’ll give us its best guess as to which deployment introduced the problem.
For performance regressions, we can correlate performance data captured over time with the deployments. In fact, services like New Relic and SpeedCurve both offer simple APIs to record deployments and surface these scenarios directly. This helps narrow things down to a few commits. From here, it’s a matter of debugging performance, but at least we’re narrowing in our possibilities.
How does release cadence influence our teams and projects?
Over the last 10 years developing code, I’ve seen a distinct correlation between the pattern of delivery over different periods of time and the qualities of teams and products.
An accumulation of undeployed changes is an accumulation of assumptions—the boat anchor of any software project. A slow release cadence early in a project isn’t uncommon, but continuing that over the long haul makes it hard to measure progress through working software. Not only is progress hard to evaluate, it’s hard to build momentum as a team when you are continuously churning with no milestones. Deployments, even to pre-production environments, provide a sense of success around which the team can rally.
Determining what your release cadence should be is tricky. As a result, I’ve worked to help teams collaborate with stakeholders in devising the most appropriate release cadence necessary to navigate the path to the right product by delivering frequently enough for you and your customers.
Deployments, even to pre-production environments, provide a sense of success around which the team can rally.
Navigating Projects
At Sparkbox, we talk about navigating projects rather than managing them. We’re constantly learning, making decisions, and re-evaluating our position. Recording your deployments might seem like a simple act with little value, but it provides our teams many of the insights and tools to make smart, quick decisions.
When I review our active projects throughout the week, I try to keep an eye on release cadence, noting where we might be accumulating assumptions without letting them reach the real world. I am able to do this by looking through each project’s deployment history and reviewing undeployed commits.
We know that no matter how great our continuous delivery pipeline is, issues will occur. Recording deployments allows us to narrow in on the cause, focus on solving the issue, and again, leverage our pipeline. Consistently and swiftly delivering solid solutions puts customers at ease, even when challenges do occur.
