Binary Artifact Management and Ansible

In a development project of any scale, anywhere from tens to thousands of artifacts are used, produced, and filed. Most of these digital fragments are in-house resources, but most organizations also utilize libraries and other resources licensed from outside companies, licensed for particular uses and, usually, for contract-specified lengths of time. Managing and complying with these requirements by hand, while possible, would take up far more time than the vast majority of organizations are willing to commit. As such, an artifact-management system should exist to manage these limitations and ensure the same version of any given resource is available to each developer, no matter where they might be. With this in mind, the concept of the artifact repository was born. A central location for all things to be used, created, and managed during the development process resides here until called upon for use in any given software project, however great or small in nature.

Managing dependencies is another important aspect of resource management that cannot be downplayed, as very few software development projects are without dependencies of some sort. Without a system to manage versions and dependencies, our developer Bob from the first Aims of Configuration Management scenario might not be able to adequately address a bug that comes up in a ticket. This is due to his lack knowledge of the correct versions of one or more resources that, when combined, cause an issue with how the software functions. These compatibility collisions are common amongst teams who dont maintain a repository for versioned dependencies.

Finally, there is the subject of governance as an important factor in the necessity for a capable binary asset management solution. Since the resources developers use for building software are not only subject to licensing restrictions, and the versions of the resources used are potentially different for each minor/major version of the products being developed, governance is key. Governance requires making sure every resource that sits in our artifact repository has been properly categorized, vetted for quality, and annotated. It ensures that all pertinent licensing and usage requirements have been met and ensures that overall development process flows as smoothly as possible. In addition, governance provides the company with a level of surety that it does not get hit with post-production license issue.

The following is a diagram demonstrating the overall workflow of workstations pulling resources from artifact repository server/machines to use in software development. Once ready to be pushed to production, the completed work is then sent up to the provisioning machine to be paired up with the appropriate playbook. Once paired with the playbook of choice, the change is then sent to the appropriate location for implementation:

Ansible, a very capable configuration-deployment tool in its own right, is limited in its built-in artifact-management capabilities. Even though many would like Ansible to be a one-stop solution for Configuration Management and deployment, it is but one of many tools in any DevOps team's toolkit to ensure timely deployment of product releases and overall mission success.

Fortunately, all is not lost, as several popular BRM tools are widely used in today's development environments that interface, augment, and complement the capabilities of Ansible while picking up where it leaves off. The following is a list of popular tools that perform well for their respective functions and interface well with Ansible. While popular, the list is neither all-inclusive nor complete, as the market for solutions to this function is always changing, new options being added constantly.

• JFrog's Artifactory (https://www.jfrog.com/artifactory/)
• SonaType's Nexus (https://www.sonatype.com/nexus-repository-sonatype)
• Apache's Archiva (https://archiva.apache.org/)
• Inedo's ProGet (https://inedo.com/proget)

With applications such as Archiva and other Maven-based artifact repository managers, Ansible already has packages built in or easily obtainable, such as maven_artifact that attempt to grab the required dependencies/artifacts from Maven-based BRMs. For others, such as Nexus, third-party modules exist that serve to make grabbing artifacts from those systems just as easy and painless.