Archive for the ‘SerenaOnDevOps’ Category

System’s programmers on the mainframe have a pretty difficult time these days. More and more complexity, rampant growth of z/Linux, Websphere and RD&T boxes. Draconian constraints, compliance and governance mandates to be applied. All with fewer and fewer resources. It is a common problem.

Serena is here to help. Our ChangeMan SSM technology is designed to be the SysProg’s best friend and unswerving ally.

Sitting quietly in the background monitoring system datasets and members like the APF authorized libraries, the LINKLIST datasets, console commands and any



(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



As the DevOps movement approaches its 5 year anniversary, the question remains: is the movement ready to cross the chasm into mainstream IT? 

Stories of unicorns abound, and if we believe the vendors and early adopter case studies for the enterprise, we would be feeling that we are on the other side of the chasm, ready to get inside the tornado, change the culture and



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.



Myth 1: Every deployment is unique

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:

  • The “payload” – what is actually being deployed and that will be code, scripts, configuration items, SQL, data and so on
  • The “set up” – what you have to do before you can deploy the “payload” like stopping servers, data migration and reformatting and backing up the environment
  • The



Logo
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



The intersection of ITIL and DevOps is an interesting one, and a topic that we have previously godzilla-mechagodzilla1974discussed. This topic is getting more and more air play as we see enterprises adopting DevOps practices like Continuous Delivery and Infrastructure as Code. After all, ITIL has been around for 25 years, and many enterprise IT organizations have adopted ITSM as their process/best practice backbone for delivering value to the



DevOpsDays attracts the best and brightest from both development and operations: the ones who want to change how companies deliver software and improve the value delivered to the business. These leaders are challenging the current state of IT, and for good reason.  The status quo is lacking in quality and not responsive enough to the business.  The DevOps leaders are looking at new ways to change the work culture, the processes that deliver software and the technologies and tools to delivery that competitive edge to the business.  Their work is driving a “BIG FAT RETHINK” on the whole traditional “People,