It’s easy to see how development teams benefit from deploy previews, but may seem less obvious how these ephemeral environments bring benefits to DevOps and IT roles across an organization. In this article in our git pull request builder series, savvy CTOs and DevOps teams share how they use deploy previews to reduce server infrastructure costs and maintenance overhead and validate DevOps processes to deploy code faster, with fewer disruptions.
The DevOps and IT professionals in an organization benefit from reduced infrastructure needs when using a cloud-hosted git pull request builder, such as Tugboat, as well as reduced time troubleshooting setups:
For DevOps and IT professionals, infrastructure needs and costs consume a large chunk of much-needed brain space. Managing infrastructure becomes a balancing act between what an organization or department “needs” versus what it costs to deploy and maintain, and in many cases, organizations are infrastructure-constrained because of cost or resource allocation considerations.
Ephemeral, on-demand environments help solve this issue when it comes to development, testing, and staging environments, as git pull request builders provide many environments where simultaneous development and testing can occur. In one Tugboat case study, a Fortune 50 enterprise client found that for the cost of a single development environment, every team could have access to dozens of pull request environments. Depending on the stack, it’s possible to replace almost every pre-production piece of infrastructure with a git pull request builder like Tugboat, reducing costs and maintenance demands while providing additional flexibility and scalability to teams.
Cut down on expensive self-hosted hardware or AWS-hosted infrastructure and CI pipeline minutes by leveraging a git pull request builder that provides cost savings for your pre-production infrastructure needs.
Not all git pull request builders are alike, but with an option like Tugboat, a git pull request builder using an infrastructure-as-code approach can replace complex, internally-maintained CI/CD pipelines for pre-production deployment.
The reality is that many talented DevOps teams could create a complex system of Jenkins build scripts, GitHub Actions, or other cobbled-together CI workflows to replicate the functionality of a git pull request builder. However, if you’ve ever worked on a team that has created internal tooling that was responsible for important processes that aren’t the core of your software, you know that maintaining these tools can be a drain on what your business shouldbe doing; creating and maintaining software that you can sell to your clients.
When you outsource the git pull request builder, you’re letting someone else take on the task of developing and maintaining this tool. Instead, your teams get to leverage technology that “just works.” Don’t ask your developers to learn Docker or manage the deploy process to get to working prototypes of their code. Use an IaC tool that can create these environments for your developers, and let them focus on development and testing.
Curious to see this in action? SimplyTest.me’s Nerdstein wrote an article about how and why he replaced his project’s backend with Tugboat - check it out.
Conducting integration testing is one of the core tasks for continuous integration workflows, but integration testing on traditional server infrastructure can become a bottleneck. Integration testing can be resource-intensive and time-consuming, and when teams only have one server where integration testing happens, it often becomes a daily job that runs overnight, or even less often.
With ephemeral staging environments, teams can spin up multiple integration testing environments with various Integration Patterns. Big-bang, top-down, bottom-up - or use collaboration integration, backbone integration, distributed services integration, or multiple concurrent Integration Patterns to test different components.
Part of the role of DevOps and IT teams is to optimize web app and website infrastructure. With Tugboat’s infrastructure-as-code approach to creating deploy previews, it’s simple to test different versions of a production-like stack to prototype and benchmark various solutions.
Tugboat’s YAML config file and cloud-hosted environments enable teams to test infrastructure changes without provisioning expensive production-like infrastructure, and without bringing additional risk or cost to in-progress development projects.
To see this in action, take a look at the solution that Lullabot’s development team tested in the Georgia GovHub migration project. Early in the process of migrating 80+ agency websites from Drupal 7 to Drupal 8, the team noticed a decline in performance during the deployment process. Using Tugboat, the team was able to test a little-used feature of Gnu Parallel to load-balance commands across multiple servers asynchronously, adding multiple PHP worker services to the configuration and eliminating the performance-degrading bottleneck.
With Tugboat’s dynamic environments, the team was able to experiment with the idea and prove it as a viable solution for production, without adding the financial burden of provisioning expensive hardware for testing or disrupting ongoing development work that continued alongside to this project.
Database backups are an important part of maintaining web development infrastructure, but how often do you test the viability of those backups? Web development agency Chromatic recently shared that one of the ways they use Tugboat is as a validation tool to test database backups.
Chromatic regularly imports their database backups into deploy previews, instead of importing databases directly from production. This ensures that their data is being backed up as expected, and makes it easy to spot issues with database backup jobs before a critical failure reveals that a database backup isn’t usable. For more details, check out Chromatic’s QA Testing with Tugboat video on YouTube.
In addition to verifying database backups, Chromatic also uses Tugboat to validate their deployment process. If a new pull request breaks a Tugboat deploy preview build, this likely signals a change that would break a deploy to production. Catching these issues early enables teams to identify problems in the deploy process long before they become exercises in firefighting while trying to push a critical release to production.
Deploy previews aren’t just valuable to development teams. These dynamic environments enable wins across the DevOps and IT landscape, whether it’s improving process or reducing infrastructure costs and maintenance overhead.
Join us next time as we look at how git pull request builders give insights into the development process to engineering managers!
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.