Bunnyshell Keeps Pre-Production Environments in Sync Automatically
You’ll find an array of guesstimates online of the amount of time developers spend managing pre-production environments. However much it is, one thing is clear: It’s time spent performing routine tasks rather than being focused on innovation.
Created in Romania but now with headquarters in the United States, Bunnyshell is taking on that problem with a vendor-agnostic, automated Environment-as-a-Service platform.
By connecting the git repository and cloud provider, Bunnyshell automatically discovers both internal and external services required to create development and staging environments identical to the production environment.
It’s synched to trace source code changes and update environments in near-real time, so if multiple people are working on the code, their environment is based on the latest code.
“We give them proper environments to develop the code so that once they have pushed it to the development pipeline, they know it’s going to work because the development, the testing and production environments are identical,” said Shani Shoham , Bunnyshell chief revenue officer.
“We do that in the cloud, so that they don’t need to work on anything on the local machine. It means that the onboarding of developers is much faster,” he said. “They don’t have to spend a week or two setting up environments locally. All the environments have pointers, so they can share that with QA, with Product, with anyone else on the team.
It also means that the feedback loop is much, much faster. QA, for example, can test isolated environments … if there’s any bug, they can immediately fix that and when they go in to build their application, it’s automatically updated on the fly.”
Identical Latest Version
Developers working on replicas that have drifted from the production environment often are left working on old versions when configuration updates aren’t applied, leading to bottlenecks in merging code and refactoring.
In a post on “works on my machine” problems, Rishi Yadav, co-founder of Roost.ai, wrote: “The real solution, though, has to involve decreasing the distance between the development environment and the production environment so that developers are automatically able to develop in an environment that’s identical to production, including having access to the latest versions of upstream and downstream dependencies and running with the same configurations.”
Working in an environment as close to production as possible reduces the number of rollback and enables more frequent releases. Bunnyshell automatically applies the changes to existing environments seamlessly, so an entire engineering team is always using the latest version.
Vendor Agnostic
Bunnyshell supports on-demand or automatic creation of production, development and staging environments.
It spins up new environments with every pull request from GitHub, GitLab or Bitbucket and integrates with Kubernetes clusters on Amazon Web Services, DigitalOcean, Google Cloud and Azure.
“We’re agnostic to whatever git repository you using, whatever cloud you’re using. We can actually support multi repos. … Sometimes each team has its own account in its own separate repo, and we can take multiple services that are on different repos and we can deploy them again on any cloud instances. So if your QA is running on GCP, and your development is running on AWS, it doesn’t matter for us. We can mix and match any service and run that on any cloud environment,” Shoham said.
Bunnyshell requires a definition of your application in a docker-compose.yml file. Behind the scenes, it performs the translation from docker-compose.yml to Kubernetes manifest. For OAuth-based version control system integrations, a user with admin permissions on the repository is required to install webhooks and deploy keys.
Actually, the project just has to be containerized. Some customers aren’t using Kubernetes yet.
“A lot of our customers, we help them on the journey to Kubernetes. We set up the Kubernetes cluster for them and then they get all the benefits of Kubernetes without actually managing Kubernetes. So we take off all the ingress policies, the security policies, the who has access to what, et cetera,” Yadav said.
It recently added support for Terraform modules and Helm charts. The Terraform modules can be defined at the project level and used later in any environment inside that project.
Bunnyshell includes a REST API for existing CI/CD and DevOps tools enabling you to easily deploy environments directly from your own release pipeline.
Additional Developer Benefits
Shoham cited increased developer productivity as the first benefit of Bunnyshell. Second is a faster feedback loop, enabling users to iterate faster. And the third benefit is managing the cost of cloud. With ephemeral environments, it only spins up what’s needed when they’re needed, and automatically tears them down afterward.
By setting availability rules at the project level, users can manage the cost of resources. Most environments, once they are built, are left on because no one takes the time to tear them down and then spin them back up in the morning, he explains. With availability rules, you can have them torn down at, say, 8 p.m. and rebuilt by 8 a.m. the next morning, saving cloud costs on running infrastructure when it’s not needed.
“Under the hood, we do a lot of caching and a lot of management of the state of the database, the state of the application, etc. So spinning them back up doesn’t take hours,” he said.
And if QA wants to do a nightly regression, it can be left up, while if developers leave by 8 p.m., those environments can be shut down.
Addressing Common Frustration
Founded in 2018 in Bucharest by Roxana Ciobanu and Alin Dobra, the company recently announced a $4 million infusion of cash, bringing investment to $6.4 million. It hired Shoham to lead its expansion in the United States.
It faces plenty of competition from the likes of Okteto, Quali, Release, Roost.ai, Qovery, Kenv.io and others, though Shoham says most prospective customers are trying to figure out whether it’s something they can build themselves — or want to.
It’s a widely acknowledged problem, though. It’s among the frustrations Quali’s Ronak Rahman cited in a post on addressing developer burnout.
