As an engineering manager, you wear a lot of hats. You manage people and projects. You need to provide input on the tech stack or software architecture. And, you’re ultimately responsible for ensuring your team is following best practices and utilizing good processes. To top it off, you may likely have to balance your attention to budget while leading teams to quickly and routinely deliver bug-free code. This is a lot for anyone to juggle - especially in 2020 - that ‘s why having deploy previews in your toolbox can help.
So how can engineering managers can benefit from git pull request builders? By gaining more visibility into what the team is working on. What do we mean?
It’s not just product and project managers who need to be able to check on works-in-progress. Busy engineering managers face the same complexities when it comes to having visibility into what the team is working on at any given moment.
Even engineering managers with development backgrounds can find it a hassle to maintain working local development environments; particularly in teams with diverse codebases that maintain different version requirements. And loading code, pulling down a database, and grabbing large assets just to check in on a pull request is a time sink - competing for precious hours that many engineering managers just don’t have.
Instead, with a git pull request builder creating ephemeral environments for every pull request, engineering managers can quickly review works-in-progress. Even better, when a stakeholder comes asking for an update or a preview of the progress, you can easily share a working version of the website or web app.
Getting feedback early and building trust with stakeholders is as easy as sharing the deploy preview URL.
This is an area where git pull request builders diverge, but Tugboat offers a range of statistics on build time and environment size that make it possible to spot potential performance red flags before they become issues in production.
Reviewing these statistics periodically provides engineering managers insights into changes in performance that could indicate upcoming issues, or give hints that there may be opportunities to review project architecture to create more performant websites or web apps. Teams can validate these infrastructure and project architecture changes with concurrent preview builds; once you start having access to this data, it’s difficult to imagine working without it.
What’s the cost to your organization when a regression or serious bug makes it through to production? At the very least, you’ll have developers pulling long hours to prepare hot-fixes, followed by the inevitable retrospectives to figure out what went wrong and avoid similar issues in the future. But repeated regressions and bugs in production erode stakeholder and client or user trust, create churn, and can ultimately cost organizations millions.
More thorough code reviews and better testing are the first steps of creating an environment with higher confidence in the release pipeline. Reducing infrastructure contention gives teams the time and space to complete those more thorough code reviews, and running automated testing against ephemeral environments is a great way to free up QA teams for more intensive manual testing. All of these things benefit from using git pull request builders to create on-demand environments.
When every pull request is merged into a testing or development branch after a cursory review, but before testing, those branches can quickly become a tangled nightmare of functional and non-working code. Release managers must cherry-pick good commits and revert or reset bad ones to create branches that are ready to release.
Validating local work with other code in a production-like environment before merging to development or testing branches maintains the known “good” state of those main branches. Testing on an ephemeral environment before merging makes it easier to confirm functionality and debug issues before they go on to cause problems in shared main branches.
We don’t want to neglect the importance of cost savings in all this. A common refrain in development and QA is “there aren’t enough environments to verify code or perform thorough testing.” Limited pre-production infrastructure leads to teams failing to review and test pull requests thoroughly before merging into development.
With a git pull request builder, teams can have access to any number of ephemeral, on-demand environments. Gone are the resource constraints of having a single development or testing server. In a recent experience with a Fortune 50 company, the enterprise found that the cost of a single server was roughly equivalent to a Tugboat enterprise plan that delivered dozens of on-demand environments. Read more about it in our case study.
With benefits ranging from building trust to recognizing cost savings, automated deploy previews from git pull requests are a great tool to add to your team’s development process.
Stay tuned for our final installment of this series as we take a look at the benefits that deploy previews provide to stakeholders of software development projects.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.