Adding to its set of DevOps tools, UrbanCode announced this month the general availability of the uRelease enterprise release-management and coordination platform. The company first announced uRelease in October 2012, but it was still in pilot then.

uRelease allows DevOps teams to plan, execute and track releases all the way to production. There are three specific problems that uRelease addresses, according to the company. The first one is the coordination of the changes across multiple applications that need to go out together, which typically have dependencies on each other.

The second problem is that, when rolling these changes into production, typically it’s not a question of just deploying software. Usually there are infrastructure changes that need to be made as part of a release as well. “Before today, there was no single system that kept track of both sets of changes,” UrbanCode CEO Maciej Zawadzki said. “It has the ability to keep track of the infrastructure changes as well as the application changes that are part of a single release.”

Zawadzki said that the third problem addressed by uRelease is the management of interdependencies among applications. To deal with this, he said, environment-management capabilities have been added.

For example, during QA testing, instances of these applications must be tested in multiple environments. “Typically, our customers have many different QA environments. And different versions of the same application may exist in different QA environments,” Zawadzki said. “For some applications, because they’re just big, heavy applications, they may not exist in every QA environment; they may only exist in one or two QA environments because they’re big, heavy, complex and expensive. So it’s not economical to have them in every QA environment. But yet, for the purposes of testing, we need to create a complete picture.”

Creating this complete picture is difficult, according to Zawadzki. “This means that there’s this complexity of, ‘Okay, my Application A is in QA environment 1. But in order for it to talk to Application B, I want to use the instance of Application B that is in QA environment 2. So, for the purposes of testing the release, I’m using the instance of Application A from QA environment 1, but it’s talking to the instance of Application B in QA environment 2.’ So we’re creating this logical QA environment for the release that spans, really, the physical environments QA 1 and QA 2.”