Abstract

One of the biggest values of using UrbanCode Deploy over other deployment systems is the integrated artifact management system, CodeStation. But as with anything in life with great power comes great disk utilization. Overall the value of having a solution that can easily fit into your organizations current state is a big win. With this power comes some additional responsibility, we need to fight the urge to keep everything, so it is helpful to have some strategies in hand and understand how cleanup works in UrbanCode Deploy.

• Why use CodeStation at all?
• Component Sources
• Cleanup Settings
• Archive
• Summary

Why use CodeStation at all?

A big selling point for UCD is the ability to drop this into an organization and immediately start collecting, organizing, and versioning the composite pieces that make up an application. Sure in theory we expect these to use some standards or share a common workflow, in practice that is less common than you think. Also this is not quite a dysfunctional as it sounds, while almost all developers have agreed and committed to using version control for source code it is not the same for configuration files, database models/schemas/migrations, deployment scripts, documentation, data, and the slew of other artifacts that go into an actual deployment.

In general I categorize this in terms of current maturity on a scale to just starting continuous integration to continuous delivery is old hat. As you start out the priority is on making the process, artifacts, ownership, and governance more visible and overall focus of improving visibility not necessarily results, that will follow naturally. As you progress and become more mature, organizational standards, best practices, and centers of excellence form around core competencies like Version Control, Build Management, Asset Management, Configuration Management, and Operational Management. Not to say that these teams and countless people are not responsible for all of these things today, I mean to say that the organization begins to realize value from them not just a team by team basis as is more common in a lower maturity org. It is not possible or even desirable even at the end state for all of these competencies to make everything uniform to a single tool, language, runtime as that is a short sited goal that ends up being a sub-optimization. The key here is to be pragmatic and understand that there is a better hammer for every problem you will face so don’t spend too much time polishing turds.

So back to the point, CodeStation provides a suitable holding pen for organizations at any level of maturity as it can act as “the source” of artifacts or merely as a proxy through to a “corporate source” of truth, and actually is just as happy to sit in a mixed mode with some teams leveraging things like Nexus/Artifactory while other teams use version control, and others just using staging file systems for artifact drops( although “that never happens!” said no one who out-sources development ever). Now you may be saying, we already solved this and everything just gets stuffed into version control before deployment. Well “Good on you!”, but there is more to deployment automation that a bunch of files, the next thing we need to look at is governance. Again we crawl (version/centralize/visualize|report), walk (script/repeat/assign|own), run(automate/govern/streamline), sprint(tune/refactor)

Component Sources

Sourcing your deployment artifacts is normally a mix of items stored in only in version control, change management databases, and artifacts derived from being built or packaged. In general the best practice for sourcing components is to use the push model, where a build tool or version control server pushes new component versions. Alternatively I would recommend we can use the Source Plugin system to source items directly from Version Control system in the case of artifacts that do not require build like configuration files or sql scripts, but those that you still want to actively version and deploy. There is also a much simpler scenarios of polling the filesystem when we don’t have anything else yet in place.

In the case where your organization is using Maven or Artifactory you can use the Maven source plugin, the “build” process is slightly different from a standard CI model. In this case you may end up using the Maven Source Plugin rather than the push model, just keep in mind that if you will be querying many Components being sourced from Maven

Cleanup Settings

An important piece of this solution is based on the assumption that UCD is acting as an intelligent staging solution, not the ultimate storage solution for deployment history and artifacts. There are three settings involved here, the System Settings, per Component level, and finally per Environment.

I describe in more detail how the clean-up process works, in the post Understanding CodeStation Cleanup in UrbanCode Deploy

Archive

CodeStation has a concept of archival during cleanup, though it is called an archive this is only a one way process. So when a cleanup happens if archive is enabled then before the component version is deleted a copy of the component files is zipped up and placed into the archive path $archive_path/$component-$version.zip If you do not already have a Asset Management strategy this can be a simple “cold-storage” type solution of old component versions once they are deleted from UrbanCode Deploy. Again note that this does not support restore, so if you really need to restore a version you can pick up this file and import back into the system. Also keep in mind, that we will only be able to create a new version, aka compA-7.zip would be restored to compA version 7a.

Summary

Using UrbanCode Deploy as a unifying staging location is a great first step to creating a common asset management solution and forming the basis of a common deployment paradigm to help improve the transparency of deployments. Focusing on your goal state by simplifying the various teams and organizations requirements to start using a common Deployment solution. Here teams will be adopting a large amount of change already as we begin to adopt the changes required for automation to succeed, getting a simple asset management in place lowers the bar to quickly integrating with the understanding that we may need to perform some amount of re-work later as we work out an enterprise ready asset management solution.

Reference:

• Apache Archiva