Multi-site Feed Replication in Action
by Olivia Glenn-Han, on Aug 18, 2016 1:00:00 PM
Software Package Managers (NuGet, Maven, Bower, npm, etc.) are an established concept, and many enterprises use Universal Package Managers like ProGet to manage and coordinate how these packages are used in the software development process. Many enterprises are global organizations that have separate functioning business units that require common packages; this is where multi-site feed replication comes in.
What exactly is Replication?
Simply put, replication is the mirroring of the same content in two otherwise mutually exclusive instances of ProGet. Many organizations need replication for things like ensuring that employees are working from the same version and ensuring that build artifacts are accessible by the necessary developer – regardless of location.
The Problem Space
Enterprises that span globally distributed locations and teams – and have multi-site data centers – often require common assets in software development.
Consider the situation where New York City is the headquarters, but Singapore, Cleveland, Los Angeles, Berlin, London, Seattle, and Tokyo all do some software development. How will teams in each location know what version of a package to use? How will they access internally distributed packages?
This is where multi-site feed replication can help. It provides the consistency and high performance standards our ProGet Enterprise users need in order to be successful.
Fulfilling the Need
By replicating feeds across all offices, enterprises are able to ensure that best practices are established, personnel are using the correct package version, and that all packages used in software development fulfill license requirements. Take, for example, one of our users who is a global online auction retailer and has acquired multiple companies that specialize in the same industry at different regional locations (e.g. Berlin and Tokyo).
Because of regional standards, regulations, norms, and localization of individual components (website, mobile apps, etc.) each separate development team is needed.
However, teams need to share and contribute packages between the different development locations. Packages such as Front-End components, login components such as username and password fields, and other common nonfunctional components like logo files, are commonly shared and need to be accessible by other development teams. For regulatory and compliance reasons, each region maintains their individual site or app and can still maintain their own individual, non-shared feeds. Feed replication allows them to share certain packages and contribute to development across all localities.
Replication in Action
For example, Berlin already has a way of implementing a feature that meets specific standards. Once the entire organization implemented feed replication, Berlin was able to share the necessary packages to all of the other development units; when Singapore wanted to implement a similar feature, they were able to do so with ease. Fulfilling a common goal with similar requirements without having to reinvent the wheel.
Whether more stability is desired or needed, ProGet's high availability architecture comes not only with multi-site replication but also ensures constant access to all the vital components in your development process.
Even during heavy load times, ProGet maintains functionality and preserves productivity, keeping enterprise-level performance standards high. Through its multi-node structure, ProGet provides a reliable, stable network with automatic failover and no single point of failure.
In other words, you'll never have to worry about what will happen when npm, NuGet, etc. experience outages. You'll be fine, regardless of your location. Just another reason why our users choose ProGet Enterprise.
DevOps in Action: Feed Replication supporting true collaboration
As mentioned above, multi-site replication is the mirroring of feeds across multiple ProGet instances. Many of our ProGet Enterprise users have a scenario that requires common components, yet their instances are in different geographic locations. Recently, one of our users described their set up of replication and how, although not geographically dispersed, they still found a huge benefit from implementing replication.
One organization. Separate teams. Common packages.
Different teams within an organization may require separate instances of their package manager. Take, for example, an industry that has strict regulations or specific security processes, like banking. A bank may have three separate instances of ProGet: Mortgages, Franchises, and Wealth Management, all "owned" by the corresponding business unit.
While all are located in the same place, their instances are kept separate for regulatory purposes. Common packages may still need to be accessed by the three business units (such as branding materials, style guidelines, etc.). By creating a replicated feed across these instances, all business units will then have access to the necessary assets while still being able to maintain their individual ProGet instances. If Franchises uploads a package to the replicated feed, Mortgages and Wealth Management will mirror that change and will then also have access to the same package in their feed. This example is reflected in the dark blue feed below.
They are also able to replicate between specific instances. This is especially useful when rolling out a feature one business unit at a time. In the above example, Franchises rolls out the feature first, then Mortgages, and eventually Wealth Management. However, say the organization has decided that Wealth Management is not ready to implement the feature, and therefore doesn't have access to the replicated feed. This is reflected in the Orange feed above.
Feed Replication Across a Common Location
Regardless of why you need feed replication, it's a useful feature that helps enterprises stay organized and ensures stability and uniformity across all teams and locations. It can be implemented in different ways and with different use cases and can be critical to your software development process and to creating cohesion among multiple internal teams or across geographically diverse offices.