5 minute read
Every business unit of IBM suffered from a development bottleneck when making changes to the core CMS platform. Teams had access to only a single development and testing server. A lengthy QA process slowed velocity and reduced confidence in what was eventually deployed to production. Stakeholders could change content and build dynamic pages, but if they ran into a bug or wanted a new feature, they had to settle down for a long wait.
The bottleneck tightened when one business unit hired an outside vendor in an attempt to speed up velocity. However, the immediate influx of 10 full-time developers only exacerbated the problem.
Enter Tugboat. With our on-premise solution, IBM accelerated development velocity without sacrificing quality and rigorous testing. Testing a new feature or bug fix used to take hours. Now it takes minutes.
The company’s development process is a common one, used in many organizations.
All approved changes in a release window are deployed to a single test server. Teams get one week to test and patch bugs until a go/no-go point for the release. After that, code that isn’t ready gets pulled, and a release happens with the approved code.
Outwardly, the process is simple. But several challenges slowed development velocity to a crawl. Each development team had only one deploy environment, limiting the tickets that could be tested and reviewed simultaneously. Testing changes locally had its own problems. Developers had to pause current work, pull down updates, reset the database, and wait for everything to rebuild. Once they were finished testing, they had to repeat the process to continue their current work. Since it was a large website, this could take hours.
The stakes were high. If a release couldn’t get approved in time for a release window, the team’s progress was stalled until the next release cycle.
Additional servers and faster resets were required, but the costs with their current hosting provider would be astronomical.
Tugboat solves these problems by building a deploy environment for every pull request.
Temporary development environments for every pull request allowed the QA team to scale as business needs demanded. No more idle team members waiting for a testing environment to be free.
Tugboat’s environments are on-demand and built in the background while other pull requests are being reviewed. No hours-long delay. No waiting for the testing server to pull all the changes and build. When QA is ready to start the review, the environment is there, at a secure URL, waiting for them.
What took hours before now takes a few minutes.
Setting up a working local development environment at a large enterprise organization can take days. And that’s just to get started. Depending on the tickets a developer is working on, a local environment can accrue a huge collection of tweaks, libraries, dependencies, and more.
All of that work takes hours to get back if the developer needs to review code for a different feature. The frequent destruction of local environments also introduces fragility, and unexpected problems can arise, further slowing the process.
These reviews now happen on Tugboat. A developer’s local environment can remain intact, and the barrier to code review is removed.
By enabling QA to test code in smaller chunks, Tugboat makes it possible to identify bugs and regressions earlier. Testing is completed faster. Issues are debugged more quickly. Teams can now deploy to the release pipeline confident that their work will make it into production.
IBM gained two things with Tugboat.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.
