Automatically debug and test CI/CD Pipeline with Dashbird

In this article, we will build a CI/CD pipeline with the AWS Cloud Development Kit (CDK) and debug a test it using Dashbird’s observability tool.

In 2021, continuous integration and continuous delivery, or short CI/CD, should be part of every modern software development process. It helps deliver new features and bug fixes much faster. If the code doesn’t have to sit days or weeks before it gets deployed, it has a higher chance that a developer remembers what they were thinking when they wrote it. And with good code quality tools, you can prevent problems before buggy code gets deployed anywhere.

API-based web or mobile apps are a well-known example for serverless systems, but CI/CD pipelines can include serverless technology too! AWS offers managed services to build serverless CI/CD pipelines in the cloud, so you only have to pay what you use.

Learn more about CDK in this crash course article.


This tutorial requires:

Setting up the Project

The project with all the code needed already exists on GitHub. You just have to fork it into your own account. This is required to give AWS CodePipeline access to your GitHub hooks.

To fork the repository, open it in your browser and click the “Fork” button on the top right. 

The next step is to initialize the project on your development machine. For this, you can simply clone your own fork.

$ git clone<YOUR_GITHUB_USERNAME>/dashbird-cicd-example.git

And finally, you need to update the credentials.json, so the project works with your own fork and AWS account.

  "github": {
    "repository": "GITHUB_REPOSITORY"
  "aws": {
  • GITHUB_USERNAME is the name of the GitHub account you forked the project to.
  • GITHUB_REPOSITORY should be dashbird-cicd-example if you didn’t change the repository name
  • AWS_ACCOUNT_ID is the ID/number of your AWS account
  • AWS_REGION is the AWS region you like to deploy this project to later

You also need a personal access token so that the pipeline can access your GitHub repository.

The GitHub docs explain how you get that token. The token needs the repo and admin:repo_hook scopes. In turn, the AWS docs explain how to add the token as a secret to the AWS Secrets Manager. The token should be a plain text secret with the name github-token.

Deploying the Project

If everything is set up correctly, the project can be deployed with just two commands. One command to bootstrap the CDK in your AWS account and one to deploy the project.

But let’s go over the project before we deploy, so you get a sense of what will happen.

In short, this project is basically two systems in one. One is the CI/CD pipeline that listens to our repository changes and executes pipeline steps when pushes happen. The other one is the actual application we want to deploy.

The responsibilities of the files are as follows:

  • bin/pipeline.js contains the entry-point for the CDK deployment. It will load the pipeline stack.
  • lib/pipeline-stack.js contains the infrastructure code for the CI/CD pipeline. It will be deployed from the command line.
  • lib/webservice/stage.js contains the glue code between the pipeline and the application stack. The pipeline will use it for one or multiple deployments of our application.
  • lib/webservice/stack.js contains the infrastructure code for the actual application. In this case, an API Gateway with one route that executes a Lambda function. The application will be deployed by our pipeline in the cloud (and to the cloud) when a push happened.
  • lib/webservice/lambda/handler.js contains actual application code for the Lambda function. In this case, it contains an error to illustrate Dashird monitoring.

The nice thing about CDK pipelines is that changes to our application code, to our application infrastructure, and our pipeline infrastructure are all handled by that same pipeline.

Let’s deploy the project. If you haven’t used the CDK before with the account and region combination you added to the credentials.json; you need to bootstrap the CDK first with the following command:

$ cdk bootstrap \
  --profile account1-profile \
  --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \

If the bootstrap worked correctly, you could now deploy the project with this CDK command:

$ cdk deploy

This can take a few minutes.

As mentioned before, this will deploy the CI/CD pipeline and not the application. After the pipeline is up and running, it will pull the repository and deploy our API Gateway and Lambda based application.

If you open the AWS console and navigate to CodePipeline (in the category Developer Tools and your chosen AWS region), you can see the pipeline working on the deployment. The last step will fail!

Debugging the Error with Dashbird

Now that the CI/CD pipeline is up and running, we can finally have look if our application works correctly. If you open the CodePipeline in the AWS console and scroll down to the bottom, you should see the below error.

AWS CodePipeline error
Figure 1: AWS CodePipeline error

If you followed the Dashbird getting started guide, all your Lambda functions will be monitored automatically, even the one that is freshly deployed by our pipeline. This means you can find that error right in the Dashbird dashboard; it should look like this:

Lambda function error in Dashbird
Figure 2: Lambda function error in Dashbird 

If you have more than one Lambda function, you can find it by its generated name, which consists of:

  • The stage name PreProd
  • The stack name WebService
  • The Lambda function’s resource name Lambda
  • A unique ID

If you click on this error, you should see the event that led to it. Below, you see the stack trace that Dashbird provides.

Dashbird stack trace
Figure 3: Dashbird stack trace

While the filename handler.js, line number 2, and the error type are correct, the location is different. It was in the lib/webservice/lambda directory on our development machine, but when deployed, it ended up in the Lambda owned /var/task directory inside the AWS Cloud. You should keep in mind to give your Lambda functions code file a name that helps to find it later.

To fix this error, we simply remove that erroneous line from our handler.js file, commit the change and push it to GitHub. This will trigger our CI/CD pipeline to run again without the error.

Wrapping up

Continuous delivery pipelines are crucial for modern software and should be part of your development process, and serverless technology is a good foundation for building your pipeline. With the CDK, such pipelines are easy to set up and maintain.

Because Dashbird follows observability principles, you don’t have to think about monitoring explicitly when creating your systems. You will get automatic preconfigured insights into and alarms for every AWS service supported by Dashbird, even the Lambda functions that are part of your CI/CD pipeline. This way, you stay up to date on your systems’ internal state and won’t get any surprises in production.

This project is based on an AWS own example project created for the AWS blog. A bit cleaned up for easier reproduction, but it’s mainly the same, so you can read the AWS article if you want to get some extra information.

Read our blog

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

More articles

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.