When we look at software builds, we’re looking, for the most part, at dependency problems. Traditional build scripting tools like Make or Ant are dependency languages. In order to do thing A, do B and C first, etc, etc. The example below, in order to build the very small program “unique” main.o and strset.o need
We include a built in package repository, CodeStation, with AnthillPro, uBuild and uDeploy. They also integrate with third party repos. We place much emphasis on this capability because it is critical for safety, governance and audit. To explain this, let’s first look at a simplified build and release lifecycle: Developers submit their work to a
Those who attended the DevOps: IT’s Automation Revolution webcast last week (slides here), won’t be surprised by my favorite slide from Glenn O’Donnell’s portion of the presentation. He discussed the challenge of moving a complex application through environments, and the likelihood of “droping the ball” and missing a piece when you go to production. To address
I’ve spent most of the last decade working on problems in build, deployment and release management. While automation has been a focus of mine, the hard part in these domains have always been around dependency management. A release day for many enterprise IT groups sees a number of application systems get updates. There’s a great
Today, there are two broad categories of provisioning and deployment automation. The first are convergent tools such as Puppet and Chef. The second are directed automation tools. You are using a directed automation tool when you deploy using your build server, or an application release automation tool like IBM UrbanCode Deploy. Agents Everywhere Both convergent and directed automation
Early this week, I noticed a lightbulb went out and we were out of spares. Instead of adding a trip to the store to my todo list, my first instinct was to order a lightbulb off Amazon with two day shipping. That would be a little crazy if I didn’t have Amazon Prime. Prime has a
I get to present UrbanCode Deploy a few times a week and the part of the demo that always draws questions is when I deploy database upgrades. Why is this spooky magic while application deployments are expected? Basically, database deployments are hard. Unlike most applications, you can’t simply replace the old version with the new.