Have you ever heard the term artifact? If you are a programmer, you probably did. If not, you are missing a great part of the picture. However, understanding artifacts is easy, and it is a gateway to continuous integration. In this post, we explain what is an artifact in code, in simple terms.
What is an Artifact in code?
Think about the definition of an artifact: the creation of an artisan. An object, completed. In fact, once an artisan finishes a craft, that craft is ready to sell. The artisan will not touch it anymore and will go to the next creation. While programmers do not produce tangible objects, they do the same thing with their artifacts. Thus, artifacts are the creation of programmers, but not all creations are artifacts.
To put it simply, an artisan is a snapshot of working code. If you are developing an application, and you reach a point where everything is working well, you can ship an artifact. To do that, you simply package all the code into a single .zip file. And that’s what an artifact in code is, a compressed file with the source code. Let me remark it again, not all source code, but instead working source code.
At this point, you may wonder where is the big deal. After all, we are just talking about compressed source code, what is the purpose of that? First, we create a snapshot by consolidating everything into the zip. While the code will evolve later, the zip will not, and will represent this version of the software. In other words, predictability. This also enables continuous integration and other amazing processes of modern software development.
Furthermore, artifacts are not just raw source code. They may contain compiled code, or transpiled/compiled assets. The code must be ready for production, and thus it may need some work before it can be packaged into an artifact.
Why artifact in code is an important concept
With an artifact, you declare a version of your application. You can deploy that very version to any server in the future, by simply obtaining that artifact and un-compressing it. And that’s the whole goal of continuous integration and delivery (CI/CD). CI/CD wants the ability to push code at will to any server, and that’s why artifacts are ideal. You can quickly pull the code, at the version you want, and do your continuous thing.
Another benefit is that you can store how your code evolves over time. That’s not in conflict with git, that should represent the code you are working on. With many artifacts, you store the various versions that you shipped to production. Do you need to roll back to a previous version? Just pull that version. It is very easy, as zip files can be stored pretty much anywhere: in an FTP server, in an HTTP server, or even in a cloud platform like S3. Azure, for example, automatically manages the creation and retention of artifacts for you, if you set up a continuous integration process. In azure, this is done with build pipelines. Each pipeline is a build a set of tasks with the ultimate goal of packaging the code into an artifact.
In Short (TL;DR)
In short, what is an artifact in code? It is code packaged for production into a zip file, compiled where needed. It is an awesome way to have a snapshot of working versions of your software, and enable you to quickly deliver updates to your production server. In the other hand, it also enables you to quickly rollback if needed. What do you think of artifacts? Do you have a build pipeline using them? Let me know in the comments.
