Gallup’s 2017 State of the American Workplace found the number of employees working remotely reached 43%, up from 39% in 2012. In 2018, finding a company that lacks distributed teams or remote employees feels like an anomaly. If you’ve worked on a distributed team, then you’re familiar with the unique culture and challenges that spring forth. For development teams, long Git clone and fetch requests compound that alienating experience with daily reminders.
Git mirrors offer a technical solution to this increasingly common concern as companies expand to distributed offices. With Bitbucket’s smart mirrors, a 5GB repository clone can take as little as a few minutes rather than an hour or more. Developers can spend more time writing and reviewing code rather than waiting for it, but it is much more than a productivity gain. It is a cultural signal that every developer’s contributions are valued (and supported) equally.
If you work with or on a distributed development team, this post will teach you everything about selecting a Git platform with mirroring capabilities that support you and your team.
How smart mirrors improve your onboarding
A new developer’s onboarding experience is their first look into company culture and process. Ensuring they have the right hardware, system access, and documentation to set up their development environment isn’t just critical for productivity. The level of care taken here leaves a lasting impression as to how invested your team is in their individual success.
For the manager of a distributed team, Bitbucket’s improvements to Git mirrors reduce the onboarding steps necessary for a new developer. You and your team will spend less time setting up Git repositories locally and encounter fewer issues due to authentication errors or incorrect fetch URLs.
Traditionally, mirroring a Git repo meant creating a new remote repository. Each remote repository still needs to fetch updates from the master repository. For a team that relies on Git mirrors, this requires configuring a remote fetch URL (mirror) and an origin push URL (primary instance). Using Bitbucket’s push proxy with smart mirrors, developers can use a single URL with the mirror. While seemingly minor, it helps your teams set up new repositories locally and create consistent technical documentation.
Day-to-day Git use
In the days of dial-up, downloading a single 3.5mb song would take 10 minutes (but only if it downloaded at the max 56kbps speed). Today, waiting more than three seconds for a web page to load is indicative of a performance flaw and that perception isn’t limited to consumer websites or applications. For distributed teams in your organization, waiting twice as long for a Git clone can be a reminder that the tools they rely on are neither close-by nor optimized to support their productivity.
A Git mirror helps your distributed teams clone and fetch like an Olympian running a 100-yard dash. That’s all that Git mirrors are supposed to do, right? Once a developer is ready to open a pull request, then it’s your CI/CD’s turn to fetch or clone the latest changeset. In Bitbucket Data Center, we want to help you scale and support the full software development lifecycle.
Many Bitbucket Data Center customers have configured their CI/CD to point to a smart mirror rather than the primary instance. Doing so allows them to manage the burst of Git requests that result from a build plan with parallel or cascading build stages.
But wait: if the primary instance in San Francisco is affected by a wide area network outage, then Sydney’s smart mirror copy can’t update and remains stale. Instead of troubleshooting why tests are running against an old build, Bitbucket has Just-In-Time (JIT) fetching. As a result, the smart mirror “knows” the local copy is stale and attempts to sync before fulfilling a clone or fetch request.
Long-term satisfaction and stability
When you work down the hall from IT, it is easy to get troubleshooting assistance, and resolution efforts are visible. But when you’re working remotely or across time zones, a technical issue or outage may mean waking up whoever is on-call but only after trying to diagnose the issue yourself.
Smart mirrors add a layer of resiliency to your team’s Git experience. We’ve reduced the points of failure that could specifically affect your team by delegating user authentication back to the primary Bitbucket instance. In the event of a system-wide outage, smart mirrors allow teams to continue cloning and fetching repositories for a period of time, even if the primary instance is down. Developers logged in via a mirror before the outage would be able to continue until the user cache expires.
Pushing forward
Distributed teams and remote employees introduce unique challenges when working to ensure employee happiness, satisfaction, and productivity. Bitbucket Data Center offers more than platform scalability and resiliency. It’s a shared, digital space where silos can be broken down across development teams and offices. If you’re interested in learning more about smart mirrors, disaster recovery, or Bitbucket Data Center’s other features, we have some great resources to dive into: