Archive for the ‘Release Management’ Category

The world of configuration management is no longer just about The future of configuration management webcast servers in the data center. It is rapidly expanding and supporting other environments including cloud, mobile devices, embedded devices, BYOD and devices in the car and home. All these environments need to be configured as a broader system tying into a business platform or application. Everything is growing and becoming increasingly pervasive,



If you didn’t see the news yesterday, our friends at CloudBees, the enterprise Jenkins company, announced further strengthening of their partner program to delivery continuous delivery success to software development and IT organizations around the world.

It was



Continuous Delivery continues to be one of the most effective approaches to improving application delivery and achieving DevOps improvement.

Serena has partnered with CloudBees, the enterprise Jenkins company, to bring you live full-day summits with industry experts on Continuous Delivery. The first four summits have been sold out and well reviewed.

Please join us at one of the upcoming summits in a city near you:

  • Chicago – October 15th
  • San Francisco



Tuesday

Like most jobs in life, preparation is the key to success. After getting to know the Serena Deployment Automation technology by working with the free version (download from the Serena website) for a few hours (see yesterday’s post) I decided it was time to try for real.

My application was a Library Management System I developed a while ago



A couple of weeks ago I wrote about downloading the new Serena Deployment Automation Appliance. This is the free, community edition of the exceptionally advanced Deployment Automation technology we introduced last year. You can get your own copy, free forever, at the community edition website.

The story so far

Since that post I have been working



“Drinking our own champagne” is how we approach technology here at Serena. If we have a our own tool that supports part of the application development lifecycle we use it for our own development efforts. In fact the Serena development teams deploy the beta versions of our solutions straight into their production environments because they want exploit the cool-new-stuff just as much as you do!

When I sat down today to start writing about automated deployment in modern enterprises I thought I’d follow the Serena mantra and “drink our own champagne” too. So I



(This is the conclusion of a 7-part series. Read part 1, part 2, part 3,



Myth: Errors happen: It’s software

Errors do occur. They occur for a reason. Often those reasons are out of our control. Someone changes an IP Address of a server. Someone changes the password to the back office system. Someone changes the name of a shared .DLL.

Of course in a well-managed and carefully controlled environment those kinds of things shouldn’t happen without the proper authentication, notification and approval. And the infamous “someone” is a responsible professional who calculates the impact of their changes and collaborates with everyone to minimize that impact. In a perfect world.

In the real world change is constant and calculating the consequences of change



Myth: Each deployment needs me

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



Myth: Emergency fixes are different

“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.