 Hi everyone, I'm Kadeshia and today we'll be looking at how to use GitHub's deployment protection rules with Honeycomb. I have senior software engineer Jason with me today here to show us how to integrate their new GitHub app in your environment to add an extra layer of security. Jason, take it away. Thanks, Kadeshia. I am Jason Harley. I am a senior software engineer at Honeycomb and I was on the team that got to build this integration with this really neat new GitHub feature. So before I get into it, deployments are something we talk about at Honeycomb a lot. We go so far as to say that they're the heartbeat of your engineering organization. And one thing that I think we truly believe and that we want other organizations to adopt is that deployments should be boring. They should be very normal. They should be happening multiple times a day, fully automated. Not something that you actually stress about. This feature from GitHub and the new Honeycomb GitHub app allows you to get sort of a final pre-flight check before pushing into an environment. Let's dive into installing the app and getting it set up in a demo repo. So here I am on my team home screen. And to install the GitHub protection app, the first thing we're going to do is jump into team settings and go into the integration center. So if you're a team owner, you will have this pretty blue button available to you to install the GitHub app. Clicking that takes us through the GitHub. We're going to use this Honey API organization, which we've used for a lot of our development and demos to date. And we are going to install and authorize the app. Very importantly in this list here, we're gaining access to read a YAML file from the root of any repository that you may set up. So let's install and authorize. Pretty straightforward, pretty easy. From there, we are going to think about what kind of query we might want to actually gate a deployment on. This feature is built very similar to Honeycomb triggers for those who are familiar with Honeycomb or for those who aren't, we're going to make a query that we can evaluate to some sort of threshold, have something been exceeded or have we met some value. So as a really simplistic deployment, my test environment here, I'm going to do a count where my HTTP status code is greater than 499 or equal to 500, whatever you're into, let's try equal to 500, and the time range doesn't really matter right now. So at the moment, there have been no errors in this test data set, and that's great. This is a good candidate for the sort of query we would like to gate a deployment on. If we're going to deploy to our staging environment, for example, we want to check that the test environment hasn't seen an abnormal level of HTTP 500 errors. So the Honeycomb deployment protection rule feature is powered by a YAML file. The YAML file looks something like this. We define a team that we're going to run this through. This is really a gate check to make sure that your app is pointed at the right environment and everything is aligned. And then we are going to pick the environment to run a query against and embed a Honeycomb query, which is a blob of JSON. If this is looking a little intimidating or maybe a little annoying, if we jump back here to the UI, any query that you run in the query builder, you can actually get an output for the JSON to run. The part here that's important is the time range, the calculations, and the filters. So jump back to my YAML file already set up here in GitHub. I have a count where HP.status code is 500. And I've introduced this really slick feature. So if you happen to be embedding your GitHub run IDs for your build into your telemetry at build time, depending on your language, there's a bunch of different ways to do this. You can match the exact version of the binary that's running in that environment to make sure that you are zeroed in. This enables things like canary workflows or just really making sure that you are getting that clean signal from your telemetry. And in this environment, we have set a tolerance of no more than three errors in the last 1,800 seconds. For those at home, that is the last 30 minutes. So we then can take and add an additional query. We can add one query per environment. And against the production GitHub environment, we are going to run the exact same query. We've used a YAML anchor here just to avoid the copy paste. If you want to run a different query in this different environment, that's no problem at all. We're using the same one here in the name of a straightforward example. So I'm doing some YAML magic to pass through the anchor. And the threshold in this environment is much tighter, though. Because before we deploy a production in our pre-prod environment, which in this case is called MS demo, we want to be really certain that the threshold was met and that we're looking really safe and securely deployed. So this is our configured Honeycomb YAML. Here's that familiar query spec again that we have taken using some YAML magic. We're going to share the same query across two environments. As we check our staging environment in our workflow, we're going to query a pre-production environment called test. And again, we're checking to see if there have been an elevated number of HTTP 500 errors. In this case, three is going to be our threshold. Before we deploy to production, though, we're going to run our query again, the exact same query, just using a YAML anchor. And this time, we set in a much tighter threshold. We only are going to tolerate one error in the last 30 minutes before doing this deployment. So jumping back into our settings, now that we have our app set up, going into environments, we can see that both production and staging have one protection rule configured already. And they are the Honeycomb custom protection rule provided by the Honeycomb GitHub app. Let's trigger CI and take a look at this deployment running through with these two gates in place. All right, so I'm going to trigger a push to CI. And let's jump in and look at that workflow run. So our build is already running. And right away, staging is now waiting for Honeycomb. We're running that query, investigating the level of 500 errors in that, and then making a decision about how we're going to advance the deployment. Staging passed, and now we're into production. The interesting part here is that if there was a failure, we're giving you the query result link to jump right into Honeycomb and start investigating what's going on here. Again, these are a final sort of pre-flight check. But your telemetry is going to help you figure out what's going wrong ultimately. So if this is how you are gaining signal into both safety or the quality of your build, we're putting it right into the query builder to look at what is going on. Jumping back into actions, we can see the production is also cleared. So we've now deployed through our build into a staging environment, into production, and used our telemetry data and a Honeycomb query to determine whether or not it was safe to do the deployment. I hope that you find the Honeycomb GitHub app and the new GitHub deployment protection rule feature empowering and a way to help your development teams push changes to your customers to deliver value. Remember that pushing code should be boring. The boring deploys exciting releases. Have fun. Indeed. Deployments should be boring and automated. Thanks so much, Jason, for showing us how to use Honeycomb's new GitHub app to add deployment protection rules in our environments. If you have questions about this feature, be sure to check out our GitHub community and like this video and share it with a dev who will find this helpful. Subscribe to our channel so you don't miss any future videos and until next time.