In case you missed it, this webinar includes code walkthroughs that help you to add observability to your pipelines (using a free Honeycomb account!) so that you and your team can speed up your deployments to prod. This is also a risk-free way to get started with observability if your team isn’t quite yet ready to change your production apps.
Achieving the deployment part of CI/CD
A huge part of having observability in your builds is gaining the ability to deploy code quickly. Many teams getting started down the path of CI/CD are excited about being able to deploy quickly—until they hit snags, struggle to fix them, and eventually spend more time maintaining their build pipelines than they do delivering software.
In a recent webinar with Honeycomb Solutions Architect Pierre Tessier, Honeycomb CTO Charity Majors discussed how teams can achieve the CD part of CI/CD and dropped this nugget of wisdom: “When it comes to software, speed is safety. Writing and deploying code is much like riding a bike or ice skating—the slower you get, the more difficult it is to stay balanced and upright.”
In other words, reducing the amount of time between when code is committed and when it’s deployed to within 15 minutes enforces a lot of good behaviors, like quick reviews.
Additionally, reducing that commit-to-deployed time interval encourages accountability since it helps ensure teams are shipping one engineer’s single set of changes at any one time, versus shipping artifacts containing multiple changes from multiple engineers. “At that point, when something goes wrong and sets off an alert, no one person will feel completely responsible for that because so many changes were shipped at one time,” explained Charity.
But the majority of teams aren’t practicing true CI/CD because they’re failing the deployment part, mainly due to the fear that they’ll break something in production. Instead, the opposite is true: continuously deploying one set of changes at a time makes it easier to pinpoint the source if an issue does arise—plus, if something does go awry, then it’s easy to find the right person to dig into the code to fix it.
“You do it enough, and it becomes muscle memory,” Charity shared. “You do it without thinking, you look at your code in production, you watch users using it, and you make sure you haven’t broken something hugely adjacent to it. Then you go on with your day.”
Reducing the interval between committing and shipping code also has another benefit: reducing burnout. “Being decoupled from your work and the impact of your work is what burns people out,” she explained. “I think the failure to adopt continuous deployment more widely is the single biggest failure of our technical leadership class of the past two decades.”
Honeycomb helps teams transition to this pattern of writing code and deploying it faster because the platform helps engineers see the changes that were deployed. And if an issue pops up, anyone can click on the changes, learn more about them, and even link back for a trace for a specific build if they wanted to dig deeper.
Pierre walked through examples of how the Honeycomb engineering team uses Honeycomb to get deeper insight into their builds and shows you how you can add observability into your own pipelines to get faster deployments.
Curious to learn more? Check out the full webinar or transcript for more details. Then sign up for a free Honeycomb account to try out the steps in the webinar for yourself. Deploy to production faster with Honeycomb!
