Managing Software Artifacts in DevOps
If you create software, you certainly create a number of software artifacts along the way. Artifacts are a natural byproduct of the software delivery process, and managing them in an efficient and secure way is critical for ensuring the health and reliability of your delivery chain.
This article explains what software artifacts are, why they matter to DevOps teams and how best to approach artifact management as part of a DevOps strategy.
What is a software artifact?
A software artifact is any type of object produced as part of the software delivery process (for example, the Continuous Integration/Continuous (CI/CD) Delivery pipeline).
Artifacts could be source code, documentation, container images, software licenses or any other type of file or resource that the team generates as it builds software. Indeed, you can think of software artifacts as the “exhaust” of the software delivery process. They are naturally produced as DevOps teams do their job.
Teams typically store artifacts in artifact repositories, which provide a secure, centralized location for managing all of the artifacts that a team creates.
Why are software artifacts important to DevOps?
Software artifacts can exist in any type of application development environment – they are not unique to organizations that have embraced DevOps.
However, artifacts play an especially important role in DevOps, for several reasons:
Reuse of resources
DevOps teams deliver software in repetitive releases. Sometimes, they may need to reuse artifacts from an earlier release cycle to help produce a later one.
For example, a documentation artifact from a previous release may be necessary for identifying known problems with that release so that they can be addressed in the next release. Or, developers may remove some source code from an application, only to discover at a later time that they need to reincorporate the code.
In cases like these, the team can reuse artifacts from earlier release cycles to keep current ones running fast and efficiently.
Team collaboration
DevOps release cycles are composed of a variety of distinct phases, such as development, testing, deployment, and production management. Each step in the process is often “owned” by a different team, which produces different types of artifacts as it does its work. Developers create source code, for example, while the testing team creates binaries, and the IT team generates documentation to keep track of issues that arise in production.
By sharing artifacts across the DevOps organization, it becomes easier for these various teams to collaborate with each other. For instance, developers may want to view documentation created by the IT team in order to discover problems that occurred in production, which the developers can then fix in the next release cycle.
Fast rollbacks
Artifacts are a vital resource in the event that a team needs to perform a rollback, which means reverting an application to an earlier version. DevOps teams typically use rollbacks to address problems that arise within a production environment. By rolling back to an earlier release that is known to be stable, teams can minimize disruptions to users while they work on fixing the root cause of the issue.
In order to perform a rollback, teams need artifacts like container images or binaries from earlier versions of an application. If they don’t have these artifacts on hand, they would have to rebuild the application from scratch. That could take some time, which is a problem when teams need to roll back a deployment immediately in order to correct an issue that is impacting end-users.
Best practices for working with software artifacts in DevOps
At a minimum, simply storing artifacts in a centralized way is a basic step toward ensuring that your DevOps team has access to the artifacts it needs, when it needs them. But teams should also adhere to other best practices that help them make the most of the artifacts they have on hand.
Keep artifacts in sync with metadata
Software artifacts often have metadata associated with them. Metadata is contextual information such as when the artifact was created or which release cycle it was part of.
In some cases, having access to metadata is just as important as having the artifact itself. When managing artifacts, strive to ensure that metadata is reliably stored alongside them, and that even when artifacts are updated or moved, their metadata stays intact.
Share artifacts across the team
As noted above, being able to share artifacts across the DevOps organizations helps different teams to collaborate and coordinate their activities. The best artifact management strategies, then, are ones that allow all team members to access the artifacts they need. You should avoid practices where each team stores its artifacts separately, making it hard for other teams to access them.
Enforce software artifact access controls
Access controls, which govern who can access artifacts, are essential for managing artifacts securely. Although sharing artifacts between teams is often beneficial, some artifacts may be sensitive in nature, and not all teams should always be able to access all artifacts.
If an artifact contains private user data, for instance, it should be stored in such a way that only engineers who have a reason to need that data can access it. Likewise, documentation artifacts may sometimes contain sensitive information that could help an attacker find the weak points within a system or application, which makes it important to set up access controls for documentation.
Retain artifacts appropriately
DevOps teams may need to access artifacts long after the artifacts are created. And even if you don’t think you’ll ever need to use an artifact again, a situation may arise where you do. You never know when you’ll need to review old source code or an application binary to research a security incident, for example.
For this reason, it’s a best practice to establish retention policies that allow you to store artifacts as long as you may reasonably need to access them. Although it’s not always practical, due to storage limitations, to retain every artifact indefinitely, you should set retention policies for different types of artifacts based on the likelihood that you will need them in the future and the cost of storing them. Artifacts that are relatively unimportant, or that consume large amounts of space, may not need to be retained as long as smaller or mission-critical ones.
Get the most out of your software artifacts
Software artifacts are a vital resource for DevOps teams. They help to minimize risks and enhance collaboration and efficiency. That’s why it’s wise to implement a secure, centralized artifact management platform, like JFrog Artifactory, which allows teams to store any type of artifact for as long as they need, while maintaining granular access controls and metadata.
