Leveraging Tugboat to facilitate cross-departmental collaboration

With many different business units working to migrate to a centralized website hosted on IBM Cloud infrastructure, this Fortune 50 enterprise had a lot of simultaneous activity writing code to a shared GitHub repository. Project managers needed a systems integration testing solution to test discrete chunks of code, and then test incrementally while conducting cross-team integration testing. Tugboat provides that with on-demand staging environments.

The challenge

Testing feature branches developed in silos

In a given moment, many different teams could be deploying to this Fortune 50 organization website’s shared GitHub repository, performing both major and minor pieces of work. Examples of these discrete feature branches include:

• The Core team working to upgrade to a new Drupal version
• The Cloud team working to implement design changes, which represent big blocks of work
• Another team developing a template that makes underlying changes with sweeping effects
• A different team working on migrations
• A team working on support and maintenance

These features are all being developed in silos, making it difficult to test across teams. Without comprehensive cross-team testing prior to merging code during the one-week testing window, the opportunity to introduce breaking changes is high, and the window in which to fix them or pull code from a release is short.

‍

The solution

On-demand environments to conduct cross-team testing

Tugboat’s ability to spin up on-demand environments gives teams the opportunity to test code not only in discrete pieces of work prior to merging into the larger code base, but also against features being developed by other teams prior to merging into a release branch. Here’s how it works:

• The team developing a feature uses Tugboat to test the feature against the last stable build; ideally, against production code. Teams that are doing both feature development and support and maintenance can test every pull request independently; a new feature can be tested in its own Tugboat environment, and a bug fix can be tested in a different Tugboat environment, both simultaneously. This bypasses constraints imposed by each team having access only to a single development server.
• Then, the team can merge both pull requests into a team-wide branch, to test the new feature alongside the bug fix and make sure the code still works as expected when it begins to interact with other changes.
• Next, project managers can pull in code from another team’s branch, and merge it with the code from the first team’s branch, creating a sprint branch that enables teams to test code against the features being developed by other teams.

With Tugboat in place, teams can spin up environments on-demand to test all of these permutations sequentially or concurrently; without the constraints imposed by a single development environment.

The implementation

Same system, different processes

Because this workflow leverages Tugboat’s basic functionality, but in a slightly different way than the existing Cloud team’s workflow, the only changes required to support cross-team testing were process-based.

Instead of merging feature branches directly into the main shared GitHub repository, those branches are first merged into sprint branches to test the code across teams. Once project managers are satisfied that systems integration testing has been completed, the code is then merged into the main shared development branch in the GitHub repository.

‍

The result

Interoperability gains, fewer release disruptions

The ability to identify bugs across silos means that teams can correct issues incrementally, and therefore faster. It also gives teams confidence when going into the week-long release testing window that the cross-team aspect of the code is unlikely to introduce any new bugs or regressions, as it has already been tested with the code from other teams prior to deployment. That lets the QA team focus on testing against production data during this time- and resource-constrained window.