I wouldn't be surprised if it is somehow related to artifacts.
- What is actually an "artifactory" (in the context of DevOps)?
- Why are artifactories used?
Artifactory is a product by JFrog that serves as a binary repository manager. That said very often one will use a 'artifactory' as a synonym of the more general binary repository, much like many people use Frigidaire or fridge to denote the refrigerator regardless if it is a Frigidaire brand or not.
The binary repository is a natural extension to the source code repository, in that it will store the outcome of your build process, often denoted as artifacts. Most of the times one would not use the binary repository directly but through a package manager that comes with the chosen technology.
In most cases these will store individual application components that can later be assembled into a full product - thus allowing a build to be broken in smaller chunks, making more efficient use of resources, reducing build times, better tracking of binary debug databases etc.
Here are some of the most popular package managers that can be managed using a binary repository:
This list is far from complete, just gives an idea of what's out there.
The binary repository can allow to host all of these under one roof, making their management much simpler for teams. Note that you do not need a very large team to start reaping benefits from binary package management. The initial investment is not very large and the benefits are felt immediately. Especially now that more and more platforms, frameworks and languages are integrating this dependency management directly in them. Their biggest advantage I have found however was to create an environment that your programmers will find natural and comfortable making it essential. It helps you as a devops creating a solid tool-chain and it helps them making the overall experience fit naturally in their stack of choice.
As I said earlier there are many products out there that can serve as binary package managers, some more generic than others in their target usage, varying also widely in their accessibility and prices.
My personal opinion is that binary repositories are as vital a part of a well designed devops setup as the source code repository or continuous integration.
You're right - being a binary repository manager it is typically used to manage storage of artifacts generated and used in the software development process.
As the first, and only, universal Artifact Repository Manager on the market, JFrog Artifactory fully supports software packages created by any language or technology.
...Artifactory provides an end-to-end, automated and bullet-proof solution for tracking artifacts from development to production.
The usages you mentioned suggest it may be popular enough for a generic trademark in DevOps.
The way it helped me understand initially, the difference between source code repository and binary repository was to think of it like: * Github or Bitbucket is useful to maintain all 'code' * Jfrog Artifactory is useful to maintain the built 'binary' At least till I was comfortable with these terms!
Also, the importance of Artifactory can be understood in relation to the philosophy of DevOps to "Build once, Deploy always". It goes a long way in Continuous Integration to build your binary once, put it into Artifactory and then call it from there to deploy into all of the different environments. That way, we are sure that the code that works in Dev is the one pushed to Prod and will work there.
Is something that is produced/generated/crafted out of a specific process
Jar out of a Java project build.
Question out of your mind
Car our of a factory
Is a receptacle where things are persisted
Github for a Java project.
StackExchange for your daunting questions
IN THEORY, an Artifact-ory would be a repository of artifact where they are persisted and managed throughout their life cycle.
In the context of DevOps, Artifactory is a product that manages binary artifacts. It stores and manages different types (Jar, Python and npm packages, etc...) that you produce out of your builds and re-use at compile or deployment time.
I think complicating things is what everybody is getting appreciated for nowadays. I will try to answer this question in short .
Source Repository is used for storing code and its versions, while artifactory is used for storing the executable programs that are outputs of those code [ binaries - dll, jar, war, ear,msi,exe files etc]
Now the reason why you would want to place them separately in a repo which is different from your code could be many right from secure access,hacking threat, malicious code check ins or to simply have a separate avenue for the clients who just need the binaries. The technology of SCM could have divulged itself into creating 2 kind of users ( one with developer privileges who will be able to access the source code and another as a client who will just be able to access binaries) but it did not take that route. So now we have artifactories.