Blog

Modern Tech Stacks need Multi-Format Repositories

Jul 19 2021/Supply Chain/4 min read
Modern Tech Stacks need Multi-Format Repositories
Modern tech stacks use multiple languages, frameworks, and tools. Cloudsmith’s Multi-format repositories are ideally suited to this environment.

At Cloudsmith, using Multi-format repositories, we provide a simple and flexible solution to deploy and distribute your software artifacts.

Multi-format repositories allow you to store artifacts of different formats in the same place. Organize your packages by environment, project, package type, or whatever way you see fit- we are not opinionated about how you organize your packages or containers.

Cloudsmith is the most flexible, universal package manager on the market, with Multi-format repositories and support for all package formats.

Diverse Tech Stacks

In the not-too-distant past, it was common to see organizations characterize themselves as Java or C# houses- it’s rare nowadays to find a project that is developed entirely in a single language.

A common project may use React for server-side rendering, Kubernetes, and Docker for orchestrating microservices and have microservices built using Python, Java, and Node.js. Different frameworks and languages are used depending on the expertise and problem they are tackling- backend, frontend, containerization- there are loads of good reasons to have multiple languages in your project- Who are we to judge your tech stack!

Many package managers don’t support a broad range of packages. That means you’ll require several repositories (Public or Private) and therefore several places that you need to manage, several places that you’ll need to integrate with your build processes, and several places that you’ll have to ensure your team has reliable, performant access to.

Other package managers don’t let you store different packages in the same repository. They make you create a repository for all your NPM packages, another for your Maven packages, and another for your Docker images. At Cloudsmith, you can do this no problem, but you don’t have to 😊

Multi-format repositories

What exactly is a Multi-format Repository? Cloudsmith’s Multi-format repositories can house all your packages in one single location- no matter what package format you are dealing with!

You can throw your Docker images in with your NPM packages, your NuGets with your Helm Charts- if it makes sense for your project and your team, go for it.

Your Multi-format repository will still work as expected with your native packages management tooling. You can use the native tooling for all supported packages- ‘docker pull’, ‘pip install’, or ‘npm install’ for example- all from the one single repository!

So while you have a single repository and a single set of processes for managing, sharing, and controlling your software assets, you lose absolutely nothing when it comes to functionality.

The benefits of Multi-format repositories aren’t just limited to development environments either. If you are distributing your software to your own customers, and you provide it in a number of different formats, wouldn’t it be nice to offer all those formats to your customers from a single location? You no longer have to worry about pushing/publishing to multiple different repositories.

Multi-format repositories make it easy to develop, deploy, and distribute software.

Universal Package Tagging

If you are worried about losing some information by changing your repository structure, don’t worry- you can enrich your packages with Universal Package Tagging.

Cloudsmith Multi-format repositories mean you can apply these tags across all the package formats you use, all in one repository.

With universal package tagging, you now have the ability to add your own searchable attributes to your packages without complicating the repository structure.

Example repository structures, please

We are not opinionated around how you organize your repositories. There are many ways to organize your repositories- below, we explore how you can structure your repositories around logical groupings of environments, projects, or package type.

Environmental specific repositories

A popular structure for customers in Cloudsmith is to have your repositories mirror your production pipeline and then use webhooks to automate deployment and promote assets.

A typical setup is to have a development, test, staging, and production repository. Once you upload an asset, you can promote it through the repositories: development -> test -> staging -> production. This structure helps keep the integrity of the asset, a provenance trail, and without the bandwidth cost of downloading from staging then re-uploading to production.

Nice and simple, easy to automate against- it’s a classic!

Project-specific repositories

I love seeing all the packages associated with a project in the same place, especially when working on a project which uses a microservices architecture with a diverse tech stack. Use your repository to help Developers visualize how the project works together.

Storing all your packages associated with a project in the same repository is a simple and practical way to organize your packages.

Package specific repositories

Of course, if you want to create a repository for each format you use, you absolutely can do that - there is nothing about Cloudsmith’s Multi-format repositories that would prevent you from doing so.
We like this structure, and it fits beautifully into many DevOps processes, but we don’t like that other providers limit you only to use this structure.

Multi-format is the best fit for modern tech stacks

Modern tech stacks use multiple languages, frameworks, and tools. Cloudsmith’s Multi-format repositories are ideally suited to this environment- a flexible universal package manager that can store any package format in whatever repository structure you choose fit.

Reduce the complexity of deploying software and gain the flexibility to structure your repositories to suit your team and processes using Multi-format repositories.

Get our next blog straight to your inbox