Testing Made Easy: How Tugboat QA Keeps Your Projects On Course

Tugboat offers a straightforward way to create working versions of your website or app for each branch in your repository, making it easier to test and share features before merging them 🚀. In this blog, we'll explore how we set up Tugboat QA for a Laravel 10 project using Jetstream with Inertia.js and Vue 3. Along the way, we'll discuss the setup process, some unexpected challenges ⚙️, and our experiences navigating the quirks of this useful tool 🔧. Whether you're curious about Tugboat or facing similar hurdles, this post has insights to help you streamline your development workflow 📈.

Tugboat time! Whoop x2!

I finally got a chance to take Tugboat for a spin on the weekend. What’s that? Its a service that lets you have working versions of your website/app for each branch in your code repository. So what? Well, it means each time your new feature is ready, you can spin up a new version of your app, then flick the link off to your client or QA team to test and review. And if you’re working on multiple features you won't be bottlenecked on your staging environment where you’d typically have one feature loaded at a time for testing.

I was looking to set up a staging environment for one of my open source projects so I thought I’d give this a try.

How to Setup

To get started you need to:

• Create an account with Tugboat
• Allow access to your repository
• Add config file to your repository (or use their API)

In your code repo, create the file at .tuboat/config.yml - This is where you would provide your infrastructure-as-code implementation.

Laravel 10 - Jetstream (Inertiajs and Vue)

I used a Laravel project to try it out. Tugboat provided a handy starter config - https://docs.tugboatqa.com/starter-configs/tutorials/laravel/ to begin with.

I created a new branch in my code repository. Added the files from the Laravel starter config and created a Pull Request on Github. This triggered Tugboat to start building a new app for me. The new app uses a secure tugboatqa.com subdomain (including SSL certificate).

Challenges

Haha! I wish it were that simple. It took a bit of trial and error to get my app working.

• Outdated Sample Configurations: The starter config provided by Tugboat did not work out of the box and required modifications for our monorepo setup.
• Node.js Installation Issues: Node.js installation failed initially due to outdated instructions, requiring a manual setup of the correct Node.js version.
• Confusing Update and Build Scripts: The provided update and build scripts were confusing and required customization to work with our setup.
• Lack of Local Setup Testing: There was no way to run the setup scripts locally, which meant every trial had to go through a full build cycle, taking 5-6 minutes per iteration.
• Silent Failures with Wrong Docker Images: Using the wrong Docker image led to silent build failures, often without error messages, making it difficult to diagnose the issue.
• Log Access Issues: We encountered an unresolved issue and have struggled with accessing the logs to understand the root cause.
• Limited Capacity: When I was finally happy with my tugboat setup I released there was a 2GB limit on the free account. My image had already used up more than its quote. This means I can only have one working copy of my branches for review. The next level up is $29 / month. A bit steep for an open source project.

Addressing Challenges and Best Practices

Despite the challenges, using Tugboat has been a valuable learning experience. It has underscored the importance of thorough documentation, clear error messaging, and the need for better debugging tools. While we are still working through some issues, the ability to spin up a working environment for each PR has significantly enhanced our development workflow. As we continue to refine our setup, we look forward to fully leveraging Tugboat's potential in ensuring high-quality code merges.