|
#redirect [[software repository]]
A '''binary repository manager''' is a software tool designed to help maintaining a store of [[binary files]] produced in software development, often storing metadata where it was built out of, and its dependencies. The repository manager helps to provide a central URL to download binary dependencies to developers and continuous builds. To make this download efficient for most binary formats a table of contents of all binary artifacts stored is provided to allow a client program to calculate the dependency graph without contacting the server. A notable exception is maven which does not have a table of contents.
== Introduction ==
Software development can be a complex process<ref>{{cite web|last1=Biggert|first1=Johnny|title=SUSTAINABLE SOFTWARE DEVELOPMENT, PART 2: MANAGING COMPLEXITY|url=http://www.johnnybigert.se/blog/2012/02/sustainable-software-development-managing-complexity/|website=Developers Dilemma|publisher=Johnny Biggert|accessdate=11 January 2015}}</ref><ref>{{cite web|title=Managing Complexity|url=http://www.economist.com/node/3423238|website=The Economist|publisher=The Economist|accessdate=11 January 2015}}</ref> involving many developers, or teams of developers working on shared code bases, accessing the same build tools, downloading and using a shared set of binary resources, and deploying components into the same software product. To manage the source files used in software development, organizations will typically use [[revision control]]. The many source files used in software development are eventually built into the [[artifact (software development)|binary artifact]]s (also known as “binaries”) which constitute the components of a software product. In addition, in order to provide their functionality and feature set, software products may use many 3rd party artifacts downloaded from free open source repositories or purchased from commercial sources.<ref>{{cite web|title=Eighth Annual Future of Open Source Survey Finds OSS Powering New Technologies, Reaching New People, and Creating New Economics|url=https://www.blackducksoftware.com/news/releases/2014-future-open-source-survey-results-revealed|website=blackducksoftware.com|accessdate=25 February 2015|archive-url=https://web.archive.org/web/20150225181718/https://www.blackducksoftware.com/news/releases/2014-future-open-source-survey-results-revealed|archive-date=25 February 2015|url-status=dead}}</ref> Consequently, a software product may comprise tens, hundreds and even thousands of individual binary artifacts which must be managed in order to efficiently maintain a coherent and functional software product. This function of managing the binary artifacts is done by a binary repository manager. A binary repository manager can be thought of as being to binaries what revision control is to source files.
==Universal package manager==
Package managers aim to standardize the way enterprises treat all package types used in the [[software development process]]. They give users the ability to apply security and compliance metrics across all artifact types. Universal package managers have been referred to as being at the center of a [[DevOps toolchain]].<ref>{{cite web |url= http://www.codeproject.com/Reference/628210/An-Overview-of-the-NuGet-Ecosystem | title=An Overview of the NuGet Ecosystem | last=Decoster | first=Xavier | date= 18 August 2013| website=CodeProject.com}}</ref>
Notable package managers include:<ref>{{cite web|url=http://www.hanselman.com/blog/HowToHostYourOwnNuGetServerAndPackageFeed.aspx |title=How to host your own NuGet Server and Package Feed | last=hanselman |first=scott |date= 13 April 2015| website=Hanselman.com}}</ref>
* Apache Archiva
* [https://azure.microsoft.com/en-us/services/devops/artifacts/ Azure Artifacts]
* [http://www.cloudrepo.io/ CloudRepo]
* [http://www.cloudsmith.io/ Cloudsmith]
* Github Package Registry <ref>https://github.blog/2019-05-10-introducing-github-package-registry/</ref>
* [[Inedo]] [[ProGet]]
* [https://jfrog.com JFrog Artifactory]
* [https://www.myget.org MyGet]
* Packagecloud<ref>{{cite web|url=https://circleci.com/blog/publishing-npm-packages-using-circleci-2-0 |title=Publishing npm Packages Using CircleCI 2.0 - CircleCI | last=canals | first=armando |date= 31 March 2018 | website=circleci.com}}</ref>
* Sonatype Nexus
== Relationship to continuous integration ==
As part of the development lifecycle, source code is continuously being built into binary artifacts using [[continuous integration]]. This may interact with a binary repository manager much like a developer would by getting artifacts from the repositories and pushing builds there. Tight integration with CI servers enables the storage of important metadata such as:
* Which user triggered the build (whether manually or by committing to revision control)
* Which modules were built
* Which sources were used (commit id, revision, branch)
* Dependencies used
* Environment variables
* Packages installed
=== Artifacts and packages ===
Artifacts and packages inherently mean different things. Artifacts are simply an output or collection of files (ex. JAR, WAR, DLLS, RPM etc.) and one of those files may contain metadata (e.g. POM file). Whereas packages are a single archive file in a well-defined format (ex. [[NuGet]]) that contain files appropriate for the package type (ex. DLL, PDB).<ref name="sharedlibrary">{{Cite journal| last = Chris | first = Tucker | title = Optimal Package Install/Uninstall Manager | publisher = UC San Diego | date = 2007-03-15| page=1 | url = http://cseweb.ucsd.edu/~lerner/papers/opium.pdf | accessdate = 2011-09-14}}</ref> Many artifacts result from builds but other types are crucial as well. Packages are essentially one of two things: a library or an application.<ref>{{Cite web| title=Linux repository classification schemes | url=http://braintickle.blogspot.com/2006/01/linux-repository-classification.html|publisher=braintickle.blogspot.com | accessdate=2008-03-01}}</ref>
Compared to source files, binary artifacts are often larger by orders of magnitude, they are rarely deleted or overwritten (except for rare cases such as snapshots or nightly builds), and they are usually accompanied by lots of metadata such as id, package name, version, license and more.
=== Metadata ===
[[Metadata]] describes a binary artifact, is stored and specified separately from the artifact itself, and can have several additional uses. The following table shows some common metadata types and their uses:
{| class="wikitable"
|-
! Metadata type !! Used for
|-
| Versions available || Upgrading and downgrading automatically
|-
| Dependencies || Specify other artifacts that the current artifact depends on
|-
| Downstream dependencies || Specify other artifacts that depend on the current artifact
|-
| License || Legal compliance
|-
| Build date and time || Traceability
|-
| Documentation || Provide offline availability for contextual documentation in IDEs
|-
| Approval information || Traceability
|-
| Metrics || Code coverage, compliance to rules, test results
|-
| User-created metadata || Custom reports and processes
|}
==References==
{{reflist}}
[[Category:Computer programming]]
[[Category:Product lifecycle management]]
[[Category:Continuous integration]]
[[Category:Software development]]
| 