Helicopters have been described as “10,000 parts flying together in close formation. It is the mechanic’s job to keep that formation as tight as possible.”
Modern software applications comprise of millions of parts when you consider the huge chunks of code we bind into our applications from the database, security, web server, communications, encryption and authentication vendors. Add to that the seemingly infinite numbers of dependencies on external web services and internal CRM and financial systems.There are 100 million lines of code in the Ford Taurus
But, just like the helicopter’s mechanic, the
“I don’t want to know why it happened: I just want you to fix it!” was what I was told early one morning by the Director of Sales. And she was right: getting the online store back online was the most important thing for the business. Blamestorming would come later.
There is a temptation at 3:00 am to just do whatever it takes to bring the system back on the air even if that means bypassing protocols and procedures designed to protect system integrity. Sales-and-Marketing and Audit-and-Compliance might not see eye-to-eye on this approach.
So why do emergency fixes have to be different? This myth is all about time. The time it takes to write the script.
In the last post we talked about some of the myths about release and deployment. Perhaps the most telling comment there was the belief that “Every deployment is unique.”
Let’s break that apart and see what it really means and why it just doesn’t hold up in reality.
Deploying an application comprises of a number of parts:
In this 7-part series we’ll look at some common misconceptions about the process of deploying software in today’s unforgiving world. Over the next few posts we tackle these myths head on and show how there is a better way.
Releasing software into the wild is exciting and terrifying. When it goes well: we party. When it doesn’t: we spend the weekend without sleep, showers, food or sleep. Wait! Did I mention no sleep already?
Too often the reason our deployments fail is because we fall into the same traps
Well it’s here! The registration for xChange15 in Washington DC opened today. Visit www.serena.com/xchange for details.
If you are a xChange alumnus, you will have been sent a discount code giving a very special price as a thank you for being a returning attendee.
If you are new to xChange, we have a special promotional code for you that will save you $300 off the full price and this is good
Two weeks ago I had the good fortune to be at the Serena Customer Day in Frankfurt. There I was able to see the latest version of Dimensions CM demonstrated by Don Irvine, Senior Director of the Dimensions Development Team. After the event I sat down with him to ask him about the work his team had been doing on the performance of Dimensions 14.
KP: Great Demo Don. I heard you mention the great work you’ve been doing on performance of Dimensions. With super-fast computers and high-speed networks why is it still important to optimize for
I’m often asked by customers how they can best modernize their software development practices. After all, many organizations are under increasing pressure to respond to their business or customer needs faster, while delivering with higher quality to on-premise, virtualized and increasing cloud environments.
Many early adopters of agile have seen the challenges of responding faster move downstream, from development to release and operations, while the business continues to request better transparency and visibility into
Last week I had the pleasure of working in the Serena booth at Agile2013 (me and a Shania Twain look-alike in picture to the right). While there were quite a few booths, some very creative, it was a fairly low energy expo area. That doesn’t mean we didn’t have some great conversations.
Agile2013 had a DevOps track. There were plenty of people who stopped by our booth who wanted to learn more about DevOps. They were
My expectations for Velocity 2013 were high, based on my experience at Velocity 2012. Once again, the folks from the Ops side of the house were out in force asking plenty of insightful questions. This year I signed up to host a “birds-of-a-feather” session (more commonly known as a BOF) on DevOps in the traditional enterprise. The session had good attendance; it was great to see interest from