Binary repository manager: Difference between revisions

Content deleted Content added
Kharnagy (talk | contribs)
m organizational update, reflect current market
m clean up, typo(s) fixed: eg. → e.g. using AWB
Line 5:
== 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}}</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>
 
Notable Universal 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>
Line 12 ⟶ 13:
* Jfrog's Artifactory
* [[Inedo]]'s [[ProGet]]
* SonaType Nexus
 
== Relationship to continuous integration ==
Line 24 ⟶ 25:
 
=== 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 (ege.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.
Line 61 ⟶ 62:
*'''High availability''' - Since a binary repository manager maintains all the development dependencies, it is vital to always maintain access to these artifacts. Any down-time of the binary repository manager can halt development with all the significant consequences to the organization. A [[high availability]] instance allows an enterprise to overcome the risk associated with downtime, through automatic failover. This is achieved by having a redundant set of repository managers work against the same database and file storage. Maintaining enterprise wide stability and performance at all times
*'''User restrictions''' - Repository managers can be integrated with other organizational systems such as LDAP or Single Sign-On servers to simplify and centralize user management. This gives an enterprise granular control over who has access to vital software components.
 
 
== See also ==
Line 68:
==References==
{{reflist}}
 
 
 
[[Category:Computer programming]]