Remove Code Review Bottlenecks with Tugboat Previews

Software peer reviews are designed to detect and correct issues early in the development process, saving organizations time and money. Whether the peer review is focused on bug fixes, performant code, requirement validation, or software quality assurance, there’s one common pain point with this practice: code reviews become a bottleneck in the software development process.

Delays like waiting for a sprint demo to share progress with stakeholders; waiting for a staging environment to be available to see the deployed code in action; or waiting for a peer to install the code locally and review - all of these obstructions impede development progress. In busy organizations with a lot of active development, pull requests or merge requests can pile up while waiting for code review, which leads to missed deadlines, unhappy stakeholders, and higher development costs.

Tugboat Previews help relieve a lot of these software peer review issues by providing on-demand deployment previews for every pull request, branch, or tag.

Improve the code review process

Plenty of code review tools exist to help analyze code, track code review progress, and share comments. But no matter how good the automated tooling is, most code reviews still require a human to look at a pull request, confirm it delivers the functionality or bug fix requested, and decide to merge it. That human involvement step is crucial, but it’s also where a lot of delays can be introduced, even among a great team of highly effective developers.

Skip the local development environment

A common bottleneck in software peer reviews is installing dependencies and setting up local development environments. If you’re tasked to peer review a pull request that relies on a lot of dependencies with very specific version requirements - which may be different from the versions you already have on your local - you’ll spend time and hassle managing those dependencies just to test code. Or maybe the PR you’re code reviewing involves downloading a massive database, or you’ve just been working on a different project and don’t have the codebase installed at all. Pull requests can sit for hours or days waiting for developers to get a working local set up on their machine to work through a code review or debug an issue.

Tugboat solves this issue by automatically creating an ephemeral development environment for every pull request or merge request. When using a GitHub, GitLab, or Bitbucket integration, Tugboat builds the environment and posts a working Preview URL or Deployment link directly to the git PR. Developers can open the Preview right from their git provider, and view a working version of the site or web app built from the code in the PR, branch or tag. No need for a local development instance to see the code in action, test for bugs or functionality, and sign off on the code review or request changes.

End the resource contention for staging environments

Another common issue that creates bottlenecks in the software peer review process is resource contention for staging environments. Most organizations have a limited number of staging environments; maybe one per product, or one per client. Some organizations don’t have staging servers at all; we’ve heard from some of our customers that getting infrastructure provisioned can mean months of red tape, while other orgs just don’t have staging servers, period. Even when staging servers are part of an organization’s infrastructure, there’s time and cost associated with maintaining them. And there are a few common refrains that make staging servers less useful, such as:

• We don’t know what’s on the staging environment right now.
• Only DevOps Andrew has the scripts to update the staging server, and he’s not available.
• There’s a code freeze on the staging environment right now while QA or Product reviews a release.
• It takes four hours to run the scripts to update the staging server, so you can look at the code tomorrow.
• We don’t have space on the staging server to copy down the full production database.
• It takes too long to copy down the production database.
• Our video delivery vendor is using the staging environment right now.

With Tugboat, you can have as many Previews as you need at a given time, limited only by the available disk space in your project. Tugboat can build these environments automatically when you open a pull request, and delete them automatically when the PR is merged, removing maintenance overhead and freeing up disk space for new builds. And you can set up Base Previews to manage large, time-intensive aspects of spinning up an environment, such as loading a large database or installing a lot of dependencies, so each new build can be up and running in a fraction of the time; often just a few minutes or less.

What does software peer review look like using Tugboat?

So what’s the process of software peer review for teams that are using Tugboat? Setting up a project in Tugboat involves a little up-front overhead, but after you’re set-up, you can interact with your development environments directly from your git provider.

Set up Tugboat

For more info about any step in this process, visit our documentation site, but the short version is:

Set up a Tugboat account and link a git provider

If you don’t already have a Tugboat account, you’ll need to create a free account and link a git provider. Tugboat offers integrations with GitHub, GitLab, and Bitbucket, or you can sign up with your email address and link git providers later.

Create a project and link a git repository

When you’ve got an account, you’ll be taken to the Create a Tugboat Project page. From here, you’ll select a repository at your linked git provider to use in your project, and choose a pricing tier - or start with a free account.

Configure git integrations to automatically build and automatically delete environments

Once you’ve got a repository linked to your new project, you can configure git integrations to automatically build and automatically delete environments. Setting up these integrations involves selecting or de-selecting a few checkboxes in Repository Settings.

Create a Tugboat config.yml file to build your environments

With Tugboat connected to your repository, you’ll commit a config.yml file in the branch, tag, or pull request that’s being built. This config tells Tugboat how to set up the services inside your Preview, and gives you the option of leveraging commands in your build process.

Commit code, make PRs, and interact with your environments at your linked git provider

After you’ve configured Tugboat, you use your regular workflow for committing code, making pull requests and conducting peer code reviews. Tugboat posts the deployment environments directly to the pull requests in your linked git provider, so you can view them right from GitHub, GitLab, or Bitbucket.

Alternately, if you want to build a branch or tag to share with someone for review, you can do that from Tugboat and share the secure Preview URL with them in whatever way you prefer. Send a product stakeholder a URL via email; ping a developer for code review via Slack, or write the URL on a piece of paper and walk over to someone’s desk while you chat about the latest episode of that TV show you’re watching. After all, you just saved a ton of time in code review; what’s a few minutes of water cooler chat?

Got questions, or want to see a demo? Contact us at support@tugboat.qa.

‍