Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

An Integrated Process for Software Delivery.

By Grant Fritchey,

There's a term that's rising to prominence in the IT world. It's actually a fairly handy short-hand for a complex topic. It brings together what can sometimes seem like polar opposites. It compresses into a very tiny space a great deal of meaning and symbolism. And yet…I hesitate to use the term, because it sounds so much like the kind of thing some marketing wonk would come up with. The term is so broad and all-encompassing that it freaks people out. It's so simple and clear that people think they know all that it means, and can therefore immediately dismiss it as not applicable in their situation. That term is DevOps.

Look up DevOps in Wikipedia and it will tell you that it is a software development method, but most DevOps advocates seem to come from the IT side of the chasm that separates developers from operations, perhaps because DevOps places emphasis on process and culture, two topics close to the heart of operations. However, don't go thinking that IT love the DevOps idea and developers hate it; brickbats fly from both camps.

Developers, enamored of the integrated approach described by the likes of The Phoenix Project or Continuous Delivery, would like to be able to respond to business need in business time, adding functionality when the need is recognized, instead of 6-9 months later after it's gone through the sclerotic IT purchasing and configuration process.

DBAs and sysadmins, tiring of being woken up at 3AM every day for the last week (month, year, decade) because of shaky code shoved into production too quickly, want more control over developers and what they do, with a slower, more methodical, development and deployment process.

These apparently-conflicting goals between development and IT prevent the integration process from occurring. There is also a lot of resistance to some of the new techniques meant to help manage an integrated process. Why would you want to put a bunch of pieces of paper on the wall as a means of process management? And Kanban just sounds stupid anyway. Continuous Delivery? Are you nuts? Let's just try one successful delivery. Talk to the developer/DBA/SAN admin/sysadmin? No way, that person is a total jerk who only knows one word ("No"). I don't care what some silly management book you read in the 80s said about process improvement, we're building software, not running a factory. The Goal? How about not taking the server offline, how's that for a goal?

So much resistance to such a simple idea. Let's just agree that we need to work together. Let's agree that we actually have a common goal. No, it's not to develop software or protect the database or administer auditing. Our common goal is to delivery functionality to the business so that we all keep our jobs. Yeah, that's right. The one thing we have in common is that we all support the business. So, let's team up. Let's figure out how to create a stream, a flow, heck call it an assembly line if it makes you happy, but a process that gets stuff out of people's heads, into 1s and 0s in app code, that then gets it deployed to the production box. Let's build infrastructure around this process so that we can automate the heck out of everything we release and test everything we release and even automate the tests. Finally let's make that process happen as fast as we can, while still protecting the business and minimizing down time.

And that's all that DevOps and all the related processes are trying to do. They're trying to find a way that we can cross the chasms that appear to surround us, but aren't really there, or at least shouldn't be. So, object to the name all you want. We don't have to call it DevOps. We can call it Bob or Ear or Achmed or Plug. It doesn't really matter what we call it. What matters is that we need to come up with mechanisms that satisfy the business need as accurately as we can and as fast as we can while still protecting the systems.

Homework? Pick up one of the books referenced here and give it a read. You won't find much mention of DevOps in Jez Humble's book but his book shares the same goals in terms of achieving an integrated process for software delivery. Stare at your belly button a while. Can't you, shouldn't you, attempt to reach across the chasms in your organization and figure out how to make development, testing and deployment faster, safer, repeatable and automated?

Total article views: 74 | Views in the last 30 days: 2
 
Related Articles
ARTICLE

DevOps

The DevOps movement has Steve Jones excited.

ARTICLE

Continuous Delivery

The practice of continuous software development is growing, with continuous integration, deployment,...

FORUM

DevOps

Comments posted to this topic are about the item [B]DevOps[/B] I have seen the like of this for a co...

BLOG

Continuous Delivery Visualization

A good one, one of the better diagrams I’ve seen. From http://markosrendell.wordpress.com/2014/03...

FORUM

An Integrated Process for Software Delivery.

Comments posted to this topic are about the item [B]An Integrated Process for Software Delivery.[/B]...

Tags
database weekly    
editorial    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones