How HotJar Sped up Its Deployments by 50% Using DevOps – InApps Technology 2022

GitLab sponsored this post.

As more companies adopt a remote-friendly workplace structure, it’s more important than ever to have an agile and cohesive DevOps stack.

For HotJar, a completely remote company with more than 100 people across 20 countries, this wasn’t just important, it was imperative.

HotJar is a behavioral analytics software product that goes beyond traditional web analytics and understands what users are really doing on a website. With both quantitative and qualitative behavior analytics tools, HotJar provides an overview of how to improve customer experience, performance, and conversion rates. The company, formed in 2014, currently has more than 500,000 customers using it to improve their websites.

Too Many Dependencies, Not Enough Productivity

Due to HotJar’s all-remote culture, scaling its communications as the company grew became one of its biggest challenges.

“The communication between 100 versus 18 people is incredibly different,” said Sara Bent, People Ops specialist at HotJar. “There’s a lot more information now. There’s an element of trying to make sure we have the information available to the team as they need it, but without drowning everybody in information which is, at points, irrelevant.”

Developers can now focus on production, rather than bugs and fixes.

One of HotJar’s core values as a company is transparency. However, sometimes being a transparent company means a slew of information coming in and out of the company for every employee to see. Initially, there was no real way to silo or filter all of this information to the right recipients. Bent frequently felt overwhelmed by irrelevant information, leading her to miss the important information she needed to focus on.

HotJar developers had originally structured their work on the cumbersome legacy systems already in place. They had to work on the codebase using those legacy tools, which was slowing productivity and hindering the delivery of relevant information to the right team members.

“The problem we were trying to solve was how to go from this [legacy system] to a more diverse setup,” said Vasco Pinho, Team Lead of SRE at HotJar, “where we still have a few infrastructure legacy pieces but also some new microservice deployments. And then how to integrate all the new things, so we could continue to grow the number of developers internally without productivity going down.”

The developers at HotJar were using BitBucket to host its source code and Jenkins for its continuous integration and continuous delivery (CI/CD). Because of the constraints of some of the legacy applications, they had to develop and maintain large amounts of Jenkins-specific code to support their pipelines. This used up a lot of resources and was an ineffective use of their time.

HotJar was also using Kubernetes as a platform for all their microservices and some of their build pipelines. They needed a solution that offered a Kubernetes integration and a replacement for their Jenkins CI/CD. While they had also tried using BitBucket for CI/CD and Concourse, neither provided the full integration solution they sought.

“In terms of a Kubernetes native product that supplies a whole life cycle, we didn’t find that many competitors,” Pinho said. “Some that we looked at we would’ve had to self-host. Jenkins X is Kubernetes-native, but we found it to be immature and it still had a lot of bugs.”

Finding the Right Match, Natively

After trying various tools to match their needs, HotJar entered a trial with GitLab. After running it locally, it quickly became clear that GitLab provided everything the team needed and more.

“While our pain points started a search for a replacement for Jenkins, once we tried GitLab’s pipelines and saw the way they fully integrated the development experience into a single tool — as well as fulfilling all our CI/CD requirements — we started considering moving our code into GitLab as well,” Pinho said. “Our developers considered GitLab’s interface and features to be superior to Bitbucket, for example, the code review flow. So we decided to embrace the whole platform.”

Where HotJar initially created a lot of custom code in Jenkins, they can now do a lot of the same work natively through GitLab. Where they once used the cloud version of Bitbucket for code management, they now use GitLab.com for all development work and to host their CI/CD runs.

“It’s not something a lot of other providers offer,” Pinho said. “We don’t have to worry about hosting the website, yet it still allows us the flexibility to run our own build infrastructure,”.

Part of the flexibility that Hotjar wants to maintain is the ability to work remotely, and do it well.

The founders “worked remotely from the outset and therefore had to establish all of these processes around working remotely,” Bent said. “That’s made sure we have this very firm foundation, ensuring that our remote communication and collaboration works well.”

GitLab’s end-to-end visibility of the workflow processes allows developers to see what everyone is working on at all times. The access to information helps to maintain HotJar’s remote communication.

Results: Increased Deployments, Better AWS EKS, and Improved Development Workflow

Today, every engineering team at HotJar — as well as some of its customer support teams — use GitLab. They all say the overall user experience is a big improvement over BitBucket, and that GitLab’s review environments are a gamechanger for any work that requires visual review. HotJar’s developers can also catch errors earlier in the pipeline, so they don’t hit the stage environment as they once used to.

GitLab’s native integration with Kubernetes also gave the development team peace of mind. Now, they can trust the tool will work automatically and without constant maintenance. Developers can now focus on production, rather than bugs and fixes. What’s more, HotJar’s build CI time has decreased by 30% over the previous implementation in Jenkins, thanks to higher density of builds per node and less scale-up operations required.

GitLab projects also connect to HotJar’s AWS EKS cluster. The tests run within the cluster, using Kubernetes Operator, then report back with coverage. Then artifacts are uploaded to AWS ECR/S3. Review environments are subsequently spun up inside the EKS cluster during review. After a merge, artifacts are deployed again to the production environment.

“We went from the deployment to production in half the time,” Pinho said.

Now, instead of hosting source code management and their own workflows, or trying to figure out why their Git repositories are down, HotJar team members are able to see which updates are in the planning process. This allows them to get back to helping their customers deliver a better experience for their own users.

Today, HotJar’s remote culture continues to thrive.

“Most people are online at the same time, so you can expect [a merge request] to be reviewed within hours or minutes, and will be able to jump on a video call to debug issues, discuss projects, etc.” Pinho said. “We definitely don’t suffer from the usual pains of fully remote offices, where queries will sometimes not be answered till the next morning.”

Just as GitLab has improved HotJar’s communication and development collaboration capabilities, it has also helped improve its level of transparency. HotJar recently published its company handbook publicly online, after seeing that GitLab’s 1,000+ page employee handbook was also available online.

“We see the similarities [between HotJar and GitLab] and it’s a reassuring thing to see what’s working really well for both of us,” Brent said of the impact GitLab has had on HotJar’s DevOps workflow and remote culture.

Feature image via Pixabay.