Binary repository manager: Difference between revisions

Revision as of 05:34, 19 February 2016

Revision as of 21:21, 19 February 2016

Line 3:

== Introduction ==

Software development can be an extremely 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}}</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==

The software and technology industry continues to change and grow, binary repository managers are no different. They are beginning to shift towards positioning as a universal package managers.<ref>{{cite web |url= https://adtmag.com/articles/2015/09/08/jfrog-repository.aspx |title= JFrog Releases ‘Universal’ Artifact Repository |last=Waters |first= John K.| date= 8 September 2015|website=ADT Mag| publisher=Application Development Trends Magazine}}</ref> These 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>

== 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

== What is a binary repository? ==

A binary repository is a [[software repository]] for binary artifacts and their corresponding metadata. It can be used to store binaries produced by an organization itself, such as releases and nightly builds, or for third party binaries which must be treated differently for both technical and legal reasons.

Line 44 ⟶ 53:

| User-created metadata || Custom reports and processes

|}

== 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

==Universal Package Manager==

The software and technology industry continues to change and grow, binary repository managers are no different. They are beginning to shift towards positioning as a universal package managers.<ref>{{cite web |url= https://adtmag.com/articles/2015/09/08/jfrog-repository.aspx |title= JFrog Releases ‘Universal’ Artifact Repository |last=Waters |first= John K.| date= 8 September 2015|website=ADT Mag| publisher=Application Development Trends Magazine}}</ref> These 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>

== Key features of repository Managers==