Replicating Bitbucket Pipelines on Your Laptop for Local Debugging
This article demonstrates how to clone your commit and replicate a serverless deployment locally to quickly diagnose and debug issues.
Join the DZone community and get the full member experience.
Join For FreeBitbucket Pipelines is one of my favorite CI/CD tools, and I use it pretty heavily daily. Given the full range of use cases available for Pipelines, I have to frequently diagnose and debug new issues, and this process of debugging starts with being able to replicate the problems in my local environment quickly.
I’m going to walk you through the process of replicating a serverless deployment locally. For this exercise, I’ll use this serverless deployment as a reference.
Clone Your Commit
Like all good CI/CD build tools, Pipelines happily gives you the actual commit-ID which triggered a particular build. In the Pipelines dashboard, the link to the commit-ID is at the top left. In my case, the commit-id is 422c59b6f54c1a4e8xxxxxxxxxx
. So once I’ve cloned my repository locally, I’m going to checkout this commit.
xxxxxxxxxx
git checkout 422c59b6f54c1a4e8xxxxxxxxxx
Checking out the same commit-ID as the Pipelines build is vital. You don’t want to check out the branch, only to find that another developer updated it right after your build. Remember that a git commit-ID is a unique pointer to a change, so use it as intended and make sure you and your Pipelines are on the same commit.
Launch Your Pipelines Container
With the clone and checkout complete, go to your clone directory and launch the same Docker container as specified in your Pipelines.
To begin, cat
your bitbucket-pipelines.yml
to identify the container you’re using.
image node 11.13.0-alpine
pipelines
branches
master
step
caches
node
script
apk add python3
npm install -g serverless
serverless config credentials --stage dev --provider aws --key $ key --secret $ secret
serverless deploy --stage dev
Launch the node:11.13.0-alpine
container and mount your current directory:
x
docker run -v `pwd`:/mycode -it node:11.13.0-alpine /bin/sh
Once the command runs successfully, you’ll be in the Docker shell. Change to the mounted directory to ensure the code is present.
xxxxxxxxxx
cd /mycode
Prepare Your Build Locally
The hard part is already over! Now it’s just a matter of executing the same build steps in this container. Only this time, we’re on our laptop instead of on Atlassian’s cloud!
In my container shell, I’m going to execute these commands:
x
/mycode # apk add python3; npm install -g serverless
I’m skipping the serverless config steps because I won’t be deploying anything from my laptop. At least not directly, and not without a PR :)
Running Diagnostics
To debug my serverless deployment, I find two things handy.
First, serverless provides a debug-mode we can enable by setting an environment variable.
xxxxxxxxxx
/mycode # export SLS_DEBUG="*"
With that done, we’ll package our serverless deployment without actually deploying it to the cloud. Sounds interesting, right? The command is as follows:
xxxxxxxxxx
/mycode # serverless package --package /tmp/myserverlesspackage
This command will create the CloudFormation package for our project and dump the files inside /tmp/myserverlesspackage. Let’s go there now and see what we have:
x
/mycode # cd /tmp/myserverlesspackage
/mycode # ls
cloudformation-template-update-stack.json
cloudformation-template-create-stack.json
serverless-state.json
...
Nice! Our serverless package built successfully. As you can see, our CloudFormation template is right there.
What we’ve done so far might now seem like much immediately, but we have quite a lot of diagnostic information already:
- If there were any errors during the package step, then you’ve already eliminated Pipelines and everything that happens after it as a potential culprit. Narrowing down on problem areas is critical to diagnosing issues.
- We can build the previous version of our project and compare the sizes of the CloudFormation templates, which can be diagnostically significant. This process is a lot harder to do on Bitbucket, especially if your build is continuously failing.
- Replicating the environment locally also allows us to play with container versions. If you’ve been changing container versions and deploying Pipelines to test them, this will be a huge time-saver.
- You can now also check the memory and CPU consumption of your build container in a controlled environment. If your Pipelines have been complaining of resource constraints, you now have a way to test it.
Local debugging avoids the friction of triggering your Pipeline every time you make a change.
Which means easier debugging, better debugging, and overall happier engineers :)
Opinions expressed by DZone contributors are their own.
Comments