This vendor-written piece has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favour the submitter's approach.
One of my favorite scenes from Disney's film Fantasia is that of the "Sorcerer's Apprentice" (originally, a poem by Goethe). Mickey Mouse, as the apprentice, is being trampled by an army of enchanted, cloned brooms. The brooms multiply automatically in an endless march to get the job done, fetching water in buckets to fill up the room and threatening to drown Mickey in the process.
For release managers responsible for software delivery in large organizations, managing the multitude of software releases can feel a lot like drowning or being trampled by an army of brooms release pipelines.
Just like Mickey, sometimes you may feel you've found the perfect magic, the one, simple, automated pipeline to command the release of your one application and daisy-chain your tools of the trade along the pipeline. And that feels great. As you configure this one "broom" to automate your chores and release this software to production.
And so, different groups in the organization may repeat this process across hundreds (if not thousands) of individual teams and applications, each focusing on their one broom, ignoring the implications of the bigger picture.
One application or a simple pipeline is pretty easy. But some of our enterprise customers need to support 20,000 concurrent applications, all in various stages of being built, tested, deployed and released. What do you do then?
High volume, high complexity, high stakes
If all you had to worry about was one single track, things would be simple. But the realities of software delivery for enterprises are rarely that simple, and the scale of software production and releases that large organizations need to support can be daunting, for two primary reasons.
The first is sheer volume. As enterprises digitize more of their business and applications become more critical, software production is going into hyperdrive, putting strains on the organization to release an ever-growing number of applications at a faster and faster pace. And for some enterprises, we're talking thousands of applications and interdependent components.
This volume of applications and velocity of releases are also mirrored in the volume of geographically distributed teams and infrastructure that develop and run these apps that need to be supported as well.
The other big issues are diversification and complexity. Devops implementation usually starts with one small team and a pretty simple pipeline. But as you want to scale devops and optimize your release processes across other teams, another tool (or 50) gets introduced into the mix.
This requires another complex process-branching. Team B needs a different pipeline than Team A. Your security officer needs to approve code promotions for teams A-through-n and review the output of tests. Team C can't have access to certain environments. Team G has a unique configuration mandating the use of 10 other similarly one-off tools and processes. You need a process to manage priorities when writing tests to a specific environment configuration that's too costly to replicate across all locations, and lock-in artifacts so that teams competing for the same resource pool do not override each other. And on and on it goes.
Sign up for MIS Asia eNewsletters.