XPath Case Study

Challenge

XPath's engineering team found themselves facing a series of bottlenecks in their development process. These issues were leading to extra testing cycles and were obstructing their ability to roll out regular updates.

One of the main problems was that their application was not containerized, which meant they had to undertake additional sysadmin tasks and often encountered the infamous "it worked on my machine" issue.

Their DevOps setup was also quite rigid, with a development and a staging environment that the team was merging into.

XPath's team utilized feature branches for every ticket, a development branch deployed on the dev environment, and a release branch deployed on staging.

The testing process was conducted in two stages, first on dev and then on staging before the release was merged to master and deployed live.

This led to increased volatility in the development process, resulting in doubled testing efforts and slower release frequency. As a result, they would sometimes postpone releases when things were not ready, were not properly tested, or had found bugs.

Solution

Bunnyshell stepped in to assist the team by dockerizing their application for development. This ensured that developers could run the app anywhere with predictability.

Bunnyshell's Environment-as-a-Service platform provided the perfect solution, allowing each branch to have a separate, isolated environment, created on-demand.

Pull requests typically stay open for 2-3 days for bug fixes and around a week for bigger features. Ephemeral Environments are created as Drafts with the Pull Request and then when they’re ready to be tested on, they’re deployed from the Bunnyshell dashboard.

Results

With Bunnyshell EaaS, ephemeral environments are initiated with the Pull request. The code is not merged until the QA has thoroughly tested the changes. This approach has reduced the testing time as they no longer duplicate testing efforts.

They have also eliminated the staging environment, with most of the testing now happening in the ephemeral environments. Small issues are occasionally tackled in dev, which now serves as the new staging environment.

On the feature branch, they would test normally, but then on the staging/release, they would not spend more than a day before deploying in production. So the savings are a few days at least, per sprint.

They saw a fast adoption, faster than she (the CTO) expected, especially on the QA. Her QA person didn’t have any devops knowledge, but with 2 short demos of Bunnyshell, she immediately picked up the flow.

Frontend developers now can connect directly to the environment with the work in progress for the backend and this way they work in parallel with the backend developers for the same feature. Previously there would be a barrier for frontends to learn how to run the backend, but now it just works.

Previously, the process was bottlenecked by waiting for the backend changes to be merged into the dev branch. Only then could the frontend connect to the dev environment, which now included the backend changes. However, these changes were not tested prior to this merge.

The most significant impact of Bunnyshell is the shift from releasing once every 2-4 weeks to a policy of releasing once a week, without any stress.