Distributed Stash

Summary

The latest release (1.4.0 January 2018) includes support for distributed Stashing so the entire team benefits from using Stashed. It is a zero-configuration setup. Services on the local sub-net discover each other and coordinate sharing jobs and their results.

Scenarios

The benefit for a single programmer switching between branches is obvious. Using a distributed Stashed network extends that value not just to other programmers, but to an entire team that needs builds quickly for design and testing iteration.

Humans

Alice and Bob are developers on the same project, sharing the same office network. Alice grabs a new library to be built with the rest of the project. When Alice finishes a local build with the library integrated with the project, she commits her changes to source control. Her fresh build of the code-base ran for over 30 minutes.

It's getting close to lunch time, but Bob just retrieved the latest code to merge before committing his own changes. Without a distributed Stash, Bob would probably be looking at another 30 minutes of build time thanks to the new library Alice pushed. However, with a distributed Stash, Bob will benefit from the work that Alice finished earlier, and Bob's local Stashed service can retrieve the results from Alice's Stash quickly. Bob's build is done in a few minutes instead of over half an hour.

Machines and Other Team Members

Continuous integration systems are a modern must-have. They create builds, run automated tests and even handle continuous delivery. A CI system can also participate in a distributed Stashed network! In the scenario with Alice and Bob above, Bob saved well over 20 minutes. Charlie, our CI server, can also realize this saving. If Charlie is responsible for getting the latest code to testers, designers and other team members on the project, the turn-around time for that delivery is much faster, which in turn reduces overall iteration times across the entire project, not just for the C++ programmers!

Current Requirements

The first release does impose a few restrictions for sharing Stashed results

• Same paths for source code on all participating nodes

• The version of Visual Studio needs to reside in the same location on remote services for the local service to fetch Stashed results

• The project directory must also reside in the same location on remote services for the local service to fetch results

• Services must be connected to the same sub-net, OR, at least one service must connect to other sub-nets for network traversal (this would be useful when sharing resources with a separate build-farm sub-net)

Upcoming Changes

Distributed Stashing will continue to accumulate new features. Removing these restrictions will happen in future releases.

• Visual Studio path restrictions will be handled automatically
• Project location restrictions will be removed
• Manual network configuration will allow for sub-net traversal without a Stashed service acting as a conduit between networks (i.e. sharing build farm resources with a continuous integration system)
• Optimizations that allow Stashed installations to scale well for very large teams