FDTE faced a challenge in their development process as they relied on a shared DevOps team for any infrastructure and CI/CD pipeline-related tasks resulting in delays for developers who had to wait for deployments and pipeline modifications.
FDTE, also known as Foundation for Engineering Technological Development, is a non-profit software development company established by professors and researchers from the Polytechnic School of the University of Sao Paulo.
FDTE's team specializes in software products and services for the financial industry and, over the past 30 years, has been working with some of the biggest banks and financial institutions in Brazil.
Sao Paulo, Brazil
100 Software Engineers
The biggest concern for FDTE's technical leadership was that the development process depended on a shared DevOps team to assist with anything related to infrastructure and CI/CD pipelines.
That meant every time developers needed a pipeline modification or a new staging environment for a microservice or had issues deploying to existing pre-production environments, they had to wait for the DevOps team.
The problem per se was not the time a DevOps engineer would take to do the work, but they were often busy with planned duties and could only pick up an unplanned ticket after 2-3 days.
I wanted to empower my developers to be able to deploy something without needing to stop anybody else in order to do that. I wanted my team to be as independent as we can from the DevOps team - it's ok if we need to plan new infrastructure and need a DevOps engineer, but not it's not ok to depend daily on different requests and minor incidents
Even though some of the developers were fully qualified to perform most of the DevOps tasks related to pipelines and deployments, they still depended on the DevOps team because they had ownership of infrastructure and CI/CD pipelines.
We were doing a deployment every other week, so that meant we were creating a new branch for that specific release and updating the staging or 'dev' environment together with the CI/CD pipeline to use this branch. This was making it very difficult for us to trace back issues to commits, development branches, or previous releases.
Gustavo knew intuitively that developers should be able to use self-service environments, but it wasn't clear to him that an out-of-the-box solution existed until he read an article from Bunnyshell on Medium.
FDTE's developers needed a way to safely deploy their applications in a cloud environment without having to depend on a DevOps team for such routine operations. On the other hand, the DevOps team needed a way to enable developers to self-service cloud environments so that they don't need to spend hours replicating Kubernetes deployments, CI/CD pipelines, or provisioning cloud services.
Bunnyshell's team ran a POC with FDTE's technology stack, and the team was impressed with how easy it was to replicate or even create an environment from scratch with all their apps, services, and databases, similar to production - without the need of a DevOps person.
Everything runs on FDTE's cloud infrastructure, and developers have access to all the tools to provision, build, deploy, and debug their applications in cloud environments without explicit access to infrastructure or pipelines.
Because 80% of the applications FDTE is developing are deployed on Kubernetes, the DevOps team just needed to provision a cluster for developers and connect it to Bunnyshell from the UI.
From there, instead of logging a DevOps ticket and waiting for 3 days, developers can now spin up a production-like environment with all the services required and deploy code from any branch or commit to it.
That takes, on average, 15 minutes, and while it's happening, they have visibility into the components that are being built and deployed, the pipeline steps as they run, and real-time logs from their containers directly in the UI.
Since everything is running in a Kubernetes-based cloud environment, pretty much what you see is what you get when pushing to production.
I can do with Bunnyshell and a DevOps person what my clients are doing with 4 DevOps people.
FDTE team is moving forward with a focus on leveraging Terraform modules and Helm charts to unlock more cloud infrastructure options for their environments.
The team plans to expand its use case to on-demand production environments in March. Despite not being at the stage of automating PR environments, the team spins up a preview environment every time they review code and perform integration tests. Spinning up an environment with a few clicks has revolutionized the team's ability to troubleshoot and trace issues.
By expanding their use of Bunnyshell, they plan to introduce it to clients as a DevOps optimization platform. Bunnyshell has allowed the team to improve their development process continuously, and they are finding new use cases weekly. The team is confident in the value they are getting from Bunnyshell and are expanding use cases gradually as their development process matures.
Because we feel we got so much value from Bunnyshell, we're not rushing the adoption, and we're expanding use cases naturally as our development process matures. We initially adopted it for internal usage and assumed the costs because we want to enable our developers, and gradually, we're also planning to introduce Bunnyshell to our clients as a DevOps optimization platform.
Bunnyshell allowed us to continuously reimagine how we develop software, and every week we're finding new use cases to leverage ephemeral environments in our development process. If we want to spin up an environment to compare this release with the previous one, we can do that with a few clicks. This approach was simply not possible before Bunnyshell.
Everything you need to know about the product and billing.