Explain Artifacts (Deployment) Like I'm Five

Comments

[Arpit Mohan]

You and your best friend Shiela decide to battle each other using clay figurines.

In order to do this, you first get your hands on the raw material - clay. In the first attempt, you manage to create a simple one with just a head, hands and legs. You keep it aside because that's the best you've got right now. On your next attempt, you learnt from your first figurine and added a sword as well. You keep that aside as well. On your 3rd attempt, you manage to add a little hat to your figurine. Each of those figurines that you kept aside is an "artifact" that you can use in your super-hero battle. For some reason, in your battle, if your 3rd figurine is destroyed, you can bring out the next best thing you've got (and so on and so forth).

In CI/CD systems, artifacts refer to the output of your build process that you would deploy. This could be a jar, tar or binary. You then deploy these artifacts onto your production servers. If you encounter issues with your current deployed binary, you could revert back to an earlier build artifact and ensure that your system continues to run (albeit with fewer features because it's the output of older code).

[Alyss 💜]

Thanks for the explanation!

[Ben Halpern]

Second this. Really wonderful visualization.

[Arpit Mohan]

Glad you found it useful! I love these series of questions. #FeynmanRocks!

[Mac Siri]

Great explanation!

[Joey Mink]

You have a killer recipe, but I can't eat a recipe:

Recipe --- [create artifacts and deploy them] ---> People eating

So you need to gather ingredients, use tools and appliances to build food out of the ingredients, and deliver (deploy) that built food (artifacts) to the people so they can eat it. Ideally, you automate and streamline every step to maximize productivity!

In the case of software, you have code, but users can't interact with code. You need to build that code, package it in a usable format (artifacts), and deliver it (deploy) to whatever location allows users to interact with it.

Any more specificity requires knowing what code you have, where it is, what kind of application it represents, etc. etc...

Hope that helps!

[Dian Fay]

Source code by itself is just static information on a computer somewhere. In order to accomplish anything, it has to be executed. This can entail a lot of extra work to produce something which can be executed: something written in C has to be compiled and linked. Java code has to be compiled to bytecode. Even though JavaScript is an interpreted language and JavaScript code can be run directly, if you're writing a library for use in a runtime like Node.js it has to be packaged in order to be useful to other projects. An artifact is the result of any of these different processes: code which has been prepared to run. It's usually compressed in a tarball or zip (Java JARs and WARs are just renamed zip files) for convenience.

Deployment is the process of putting an artifact where it needs to be and performing any tasks it needs in order to fulfill its purpose. Artifacts can be a huge range of things: desktop applications, web servers, "servlets" in Java which get dropped into a servlet container like Tomcat or Glassfish to become a functioning web application, tools, utility libraries, hardware drivers. For a web application, deployment could look like pushing the artifact to a server, extracting it, running some initialization scripts, and finally executing the code that starts the application listening for HTTP requests. A desktop application gets bundled into an installer and made available for download. A utility library is pushed to a repository where its dependents can access it: the npm public registry, Maven Central, private Artifactory or Nexus servers for proprietary code.