XPath.global encountered a significant hurdle in their development process due to the lack of application containerization and a static DevOps setup. This resulted in doubled testing efforts, and slower release frequency, causing delays for developers who had to wait for deployments and pipeline modifications.
XPath.global, a leading global mobility marketplace ecosystem, was established in 2018 with the aim of revolutionizing how enterprises interact with mobility service providers through digital tools. At the time of this case study, the R&D team at XPath consisted of 10 software engineers, led by their CTO, Laura Michaud.
10 Software Engineers
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.
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.
The ideal solution for us was to have a way for the QA to be able to test in isolation before merging the code to the dev or staging branch. When there were a lot of things being merged together in order to be tested and we’d see a problem, we wouldn’t know where the issue was coming from.
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.
Bunnyshell helped us by abstracting DevOps for our team, we don’t need a dedicated resource in the team, with the current knowledge the development team has we can handle most tasks related to testing and deployments.
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.
The most measurable impact we have from Bunnyshell is going from a release once in 2-4 weeks, to having a policy to release once a week, and nobody’s stressed about it
Everything you need to know about the product and billing.