|Product Marketing||Technical Marketing||Product Management|
|Parker Ennis ( @parker_ennis )||Itzik Gan-Baruch ( @iganbaruch )||Tim Rizzi (@trizzi)|
As an Admin at a large, enterprise organization you need to enable your developers to point their tools like Maven, npm,or pip at a local proxy server for all of the dependencies that they need. The server must be able to fetch dependencies from remote repositories, cache the artifacts, and be able to export its database of them to an air-gapped system at a regular interval. You need the ability to easily apply policies when dependencies are initially downloaded—either scanning them for security vulnerabilities or applying some other selection criteria (allowable license, allowable package author, etc.).
Well the air-gapped requirement might be a bit much, the above is what I typically hear from our customers. You can just as easily add in requirements like geo-replication, high-availability, and auditing. If you are a large organization, you need help with package management. Why large organizations? Well, smaller development teams can typically work with the myriad of package manager solutions out there because they likely:
For large organizations:
I guess you can surmise from reading the above that the problem of package management is tough for large, complex organizations. So, why make it harder by spending more money on additional tools. The trend towards consolidation make sense. It's why companies like JFrog and Sonatype have been striving to expand their products from universal package managers to complete DevOps platforms.
GitLab can save you money and time with the GitLab Package offering. In the below article, we'd like to walk you through the requirements of a package management tool, how GitLab compares to the competition, and how you should evaluate vendors.
The personas for this use case are going to focus on large, complex organizations that need a tool for securely managing dependencies in a variety of formats from many different sources.
As we execute our 3-year strategy, our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams.
Software developers have expertise in all sorts of development tools and programming languages; an invaluable skillset to help ensure usability and consistency throughout the entire application development process and software development ecosystem while managing packages, storing and distributing images, and more.
DevOps Engineers have a deep understanding of their organization's SDLC and provide support for infrastructure, environments, and integrations.
|1) Package Registry||The GitLab Package Registry acts as a private or public registry for a variety of common package managers. You can publish and share packages, which can be easily consumed as a dependency in downstream projects.|
|2) Container registry||A highly scalable application that stores and lets you distribute Docker images.|
|3) API||An API for all features is required for supporting your customer workflows.|
|4) Storage management||Dependencies can build up fast. You need a way to manage storage costs.|
|5) Extensive metadata||Dependency metadata is required to validate you are using the correct one.|
|6) Dependency scanning||Automatically find security vulnerabilities in your dependencies while you’re developing and testing your applications.|
|7) Dependency firewall||Prevent the introduction of security vulnerabilities from external dependencies|
|8) Virtual registries||A collection of local, remote, and other virtual repositories accessed through a single logical URL. This hides the access details of the underlying repositories letting users work with a single, well-known URL.|
|9) High availability||A highly available product will ensure your teams stay productive|
|10) Geo replication||You can set up a Docker Registry on your secondary Geo site that mirrors the one on the primary Geo site.|
|11) Searchable dependencies||It should be easy to search for and discover dependencies.|
|12) Certified dependencies (or images)||Protect important dependencies from being corrupted or overridden.|
In the past two years, we've delivered a ton of features with a relatively small team. In the next two years, we are going to accelerate our product roadmap to deliver a solution that delivers all of the market requirements for a universal package manager.
We will do this by growing the Package team, building products that are aligned with your needs, and continuing to grow and support the GitLab Community.
More content to come as we iterate