Dachary Carey
Git pull request builders provide valuable benefits across broad swaths of web development organizations. One way to explore the benefits that these deploy preview tools provide is by looking at how they enable different roles within a software development organization to get work done faster and better, and collaborate more effectively. In today’s article, we’ll look at how deploy previews improve the software development lifecycle (SDLC) for project and product managers.
Git pull request builders are a great tool for project and product managers who want insight into project progress. These tools enable things like:
Project and product managers don’t always have easy insight into in-progress tasks. When checking on tasks requires a project or product team member to maintain a working local development environment, that can turn into a blocker. Local environments can become corrupted quickly, especially with complex dependencies to manage.
Checking the state of a migration can be a herculean task involving managing the appropriate version of a database and fast-forwarding or rolling-back changes. Even in a best-case scenario with few dependency changes or version conflicts, pulling down new code or large databases takes time - time that these busy individuals often lack.
Enter the git pull request builder. When an environment automatically spins up every time a team opens or updates a pull request, the busy product or project manager can quickly click into these environments and check in on project status - without needing to deal with a local environment.
The Senior Technical Project Manager in our Fortune 50 Development Process case study, Lullabot’s Chris Albrecht, says:
“With Tugboat, I haven’t had to set up a local environment, EVER.”
This is particularly valuable for large teams or organizations where many feature branches and support fixes are underway at any given time. This high-velocity Fortune 50 development team has many pull requests open at a given moment. With an average time of a few days to set up a local environment, and high complexity to update the local environment for different dependencies and testing different migration pull requests, not having to maintain a local as a project or product manager is a huge time saver.
With website previews for every pull request, product managers and project leads can see and use the functionality for each discrete piece of work at any given moment. They don’t have to wait weeks for an entire release to be bundled up and deployed to a single QA or staging server. Instead, a project or product manager could click into 5 or 10 pull request previews in a day to resolve blockers or do a quick status check during scrum, providing a dramatically improved experience for project and product managers.
A good software development user story involves writing good acceptance criteria, but product managers are the ultimate arbiters of whether feature implementation meets end users’ needs. Unfortunately, in many web development processes, product managers don’t get to try a working version of the product until the entire release is bundled up and deployed to a staging or UAT environment.
Git pull request builders create full, working websites for every pull request. This means that product managers can see the real-world code in action, and go through the functionality just like an end user - potentially weeks or months earlier than they would see it in staging or UAT.
This gives product managers a chance to not only verify user story acceptance criteria, but spot gaps where developer interpretation of a user story isn’t accurate, or where the happy path fails and things don’t work as intended. This early feedback enables quick rework and tight collaboration with the development team, which leads to faster development and a better end-user experience.
The project or product manager is often the intermediary between the development team and key stakeholders; whether those stakeholders are C-level executives or external clients. Sharing progress with those stakeholders isn’t always easy.
In many scenarios, a project or product manager only sees some screenshots of the new functionality in a ticketing system, where developers and QA confirm the functionality works according to the user story. For important or key features, teams may go one step farther and prepare and schedule a demo, where someone in development or QA “drives” a tour through the new functionality while an interested stakeholder looks on.
Compare that to the experience a stakeholder receives with a deploy preview. A git pull request builder provides a URL to a fully-functional environment, where a stakeholder can click around and explore the new functionality at their convenience. This provides a much better experience for the stakeholder, and it also elicits better feedback about new functionality.
In our case study about how the Digital Services Georgia team uses Tugboat to improve the SDLC, Engineering Lead Jenna Tollerson talks about how Tugboat allows her to share work with stakeholders:
“When I prototype new features for stakeholders, Tugboat allows me to present the idea on a working site, and gather feedback asynchronously.”
The ability to share works-in-progress with key stakeholders is transformational to the development process; use this to grow trust, build consensus, or pivot early before committing substantial development resources to a path that won’t get approval.
Today, we explored how git pull request builders benefit product and project managers by enabling easy status checks of every pull request, providing opportunities to verify and spot gaps in user story acceptance criteria, and serving as a tool to more effectively share progress with stakeholders. In our next article in this series, we’ll look at how deploy previews enable UX and UI design teams to easily review front-end development work, share work with stakeholders, and collaborate more effectively across teams.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.
