The Service Fabric allows a federated approach to repositories. By this we mean that a federated hierarchy of virtual or physical repositories may be created which align to organizational structure, and / or how software components are sourced: i.e.
- Open Source.
- Gated Community.
- In-house developed components used across the organization.
- Business specific components.
- Application specific components.
This federated approach allows long term optionality with respect to how software components are sourced and subsequently maintained; this while maintaining strong management and governance.
How does the Service Fabric enable this flexibility?
Each System imported to a Fabric, via its '
repopath', references the repositories required to assemble the System's runtime structure: see Systems & Repositories. While each System may reference multiple repositories, runtime access to those repositories is controlled by the host Service Fabric via its
repositoryWhitelist configurations: see Configuring a Fabric. If an imported System references a repository which is on the host Fabric's
repositoryBlacklist; the System will be marked as
The Service Fabric can be integrated with your existing in-house repository service. A Service Fabric may also be used with popular repository products including Nexus and Artifactory, or for evaluation purposes a simple file system based repository like SFS, and Paremus can advise on the advantages and disadvantages of the various options available.
Paremus can assist in the formulation of a Continuous Integration / Repository strategy to meet your Agile development goals (see OSGi Alliance White Paper - Agility and Modularity: Two Sides of the Same Coin.), and your organizations Governance, Operational and as shown in the next section Business Continuity objectives.
This section documents the relationship between Systems, their host Service Fabric environments and external repositories.