In the next few weeks Serena is going to be announcing important new versions of our ALM, Release and Deploy solutions.
Ever since Serena’s CEO, Greg Hughes, introduced the concept of “Move Fast Without Breaking Things” at our User Conference in Washington DC in February, we have seen an overwhelming acknowledgement from our customers and partners that this is the perfect encapsulation of what modern application development and deployment means to them.
For Highly Regulated Large Enterprises (we call
Well! We’re all set to go! We have a great agenda, a fantastic lineup of speakers and some fun activities planned. If you haven’t registered yet there is still time – you can register here.
Let’s take a quick tour of the highlights …
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
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
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.
The third day of the expo started at 10:30 this morning. It was very quiet competing against a very full and interesting agenda in the general sessions.
It was very rewarding to see so many customers come by and talk about their experiences with ChangeMan ZMF. We had one customer, who had been working as a ChangeMan ZMF Administrator for over 20 years, come by with his intern, a young college graduate who was being trained to take over from him when he retires. It was very moving to see one generation handing off to the next.
SHARE runs a fun competition for the attendees with some excellent prizes. They asked us for a question to add to their quiz and so we asked, “ChangeMan ZMF has been the
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 over and over again. We never have time to step back and do it right so we keep on doing it the best we can and that is where the