Kevin Parker Archive

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 software and release engineers can’t be there all the time the system is on the air (or in the air).

It would be prohibitively expensive to have engineers chaperoning their application 24×7. Yet, whenever there is a deployment, no matter how routine, release engineers “want to be there just in case.”

This is laudable commitment to ensuring success but belies a worrisome truth. Is the release engineer who hangs around the release “just in case” more capable than the one who doesn’t hang around but gets on with the next release automation task?

Deployment Automation maintains an inventory of every artifact deployed

Automation means never having to say you’re sorry

Release engineers who build automated deployments know that they can incorporate all the necessary logic to deal with the expected (and unexpected) consequences of their deployments. They know they can leave the automation to execute quietly and efficiently without human intervention.

Automation engineers also know if that if something occurs that has not happened before they can a) handle that safely too and b) add further automation to deal with this new exception in a proper, predictable fashion each time it occurs in the future.

Serena’s Deployment Automation technology release engineers are freed up from constant script development and modification. Now release engineers can turn their attention to supporting the development teams and enabling their continuous improvement programs, their continuous integration process and their continuous delivery goals.

Instead of firefighting every failed script and every broken deployment, release engineers can use the Serena Deployment Automation logging capabilities to do full root cause analysis of problems that arise. Then they get to address the problem at its source by improving the coverage and completeness of the automation eliminating the possibility of future errors occurring.


In order to help you get started with your automation, Serena has made their latest version of Serena Deployment Automation available in a Community Edition format that lets you experience the most up-to-date deployment automation technology for free. Download it here today.

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. The time it takes to execute the script. The time it takes to get the system back on the air.

Approvals where you need them

Half the effort and a tenth of the time

With Serena’s Deployment Automation we can halve the time it takes to create a script and we reduce that actual deployment times by 90%. And we do not bypass the audit controls, the change reporting or the system integrity.

Whether you are changing one setting in a DNS configuration or every .DLL in the application the procedure for updating your application is the same. You should not rely on the skill, experience and knowledge of a tired release engineer who is working under the pressure of a very upset executive. It is at these times when you must rely upon proven and reliable solutions that deploy consistently, safely and quickly.


In order to help you get started with your automation, Serena has made their latest version of Serena Deployment Automation available in a Community Edition format that lets you experience the most up-to-date deployment automation technology for free. Download it here today.

Myth: Every target is unique

When we started this series we talked about how release engineers have difficulty in keeping up with the rate of change in their environment. Every day a new security patch or software update is applied that changes the known topology of one or more deployment targets.

This is why, some release engineers insist, they have to hand-craft the deployment scripts each and every time.

In an ideal world every target environment would be standardized. But we don’t live in an ideal world. Whether it is our own on-premise platforms, virtualized or cloud platforms we know that their configurations are in a state of constant evolution. This makes it hard for release engineers who must spend time determining the target topology before they write and execute the deployment script.

Any time we rely upon humans we introduce the possibility of error. What if we could detect the target topology before we deploy and then follow a script for that combination of configurations?

Serena’s Deployment Automation allows you to do just that. In fact it even allows you to stand up your virtualized and cloud-based platforms right there in your deployment thus ensuring that the deployment target is what you expect it to be.

All new process editor

Out of the box Serena Deployment Automation integrates with many third party technologies. Everything from your favorite code repository and build tool to your deployment and test technologies and it even integrates with your problem management system.

Using a graphical design environment, release engineers can construct their deployment automation quickly and design it so that different logical paths are followed depending on what target topology is encountered.

Now you get to build upon your proven automation and keep pace with the evolving landscape that surrounds you.


In order to help you get started with your automation, Serena has made their latest version of Serena Deployment Automation available in a Community Edition format that lets you experience the most up-to-date deployment automation technology for free. Download it here today.

Tags: Serena

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 leading mainframe software change, configuration and release management solution for 29 years. What was it originally called?” Do you know the answer? Post your answer in the comments section – sorry no prizes. I’ll post the answer next week.

Keep following the tweets @SerenaSoftware and @KevinParkerUSA.

And don’t forget to watch my presentation live from SHARE on the SHARE Live tomorrow at 08:30 Eastern Daylight Time

Download the community edition for FREE today

The exciting news of the day is the immediate availability of the Community Edition of Serena Deployment Automation.

If you want to simplify and automate software deployments, then download the Community Edition of Serena Deployment Automation. By the end of the day you’ll be enabling continuous delivery for your dev teams and production deployments for your ops teams. You’ll be enabling the deployment pipeline and reducing cycle times faster than you thought possible. With Serena Deployment Automation, you will deliver high-quality, valuable software to your target environments with repeatability and predictability.

This is what customers are already experiencing …

  • Deployment time reduced by 90% and effort by 50%
  • End-to-end deployments in the cloud and on premise – including mobile devices
  • Out-of-the-box integration with your entire DevOps tool-chain
  • Developer self-service enablement

… time for you to be part of the community.

Is it really free?

Yes! And it’s free forever! This is not a limited-time trial, this is not a limited functionality offer. You can download the fully functional product, templates, samples and quick-start guides. We have limited this version to five end-points so you can experience all the features of the very best in deployment automation.

When you’re ready, you can upgrade to the Professional Version for just $1,499 an end-point and you still get to keep your original 5 for free.

Installation is easy!

We have even configured a virtual appliance with all the operating system, product and samples already configured. You can download your appliance today and and be up and running minuted later (you’ll need to download the Virtual Box software for your platform (Windows, OS X, Linux, Solaris) to use the appliance.

Included are four common deployment templates and there will be more in the future.

Or download the full product for your platform and follow the simple installation guide to be up and running your own customized Deployment Automation solution.

What about support?

The Community Edition is supported by the Development Automation community of users. You will be directed to the community when you sign up for the download. You can see there are several threads already chatting about how to get the most out of Serena Deployment Automation.

Once you’ve downloaded the product we’ll check in with you in a few days to see how it’s going. If you like it you can keep using the Community Edition for as long as you like and you can even get updates as and when they become available. And its still free. Forever. Once you’re ready to upgrade to the Professional version simply contact us and we’ll help you extend your deployments to your entire enterprise.

We even have support for the mainframe in the Professional Edition.

So? What are you waiting for?

It’s time to try the Community Edition now and start deploying before you go home. Get your deployment automation started and experience the most up-to-date deployment automation technology for free. Download it here today.

Buzz words from today's sessions

Buzz words from today’s sessions

I just slipped away from the conference to pen a few notes about today here at SHARE. There are more than 1,000 attendees from all over the world and it is great to see so many familiar faces once again.

The opening address this morning was a very salutary reminder that we live in a world of constant threat to our computer systems. It isn’t just threats terrorists from without and disgruntled employees with anymore. Now we face more sophisticated challenges from cyber criminals, foreign and domestic security agencies and kids in dorm rooms. Keeping pace with those threats is probably what most IT/IS departments strive for. Clearly that is a losing proposition so we need to turn our focus on getting ahead of the threats on one hand and hardening our systems on the other hand. Its like a sinking ship: you can bail water, your can try to plug the hole but it’s best if you do both.

Today I took time to look at mainframe trends and one thing that caught my eye, and it came up in a number of sessions, was the idea that mainframe skills are not that different from the skills used, in all fields, on non-mainframe platforms. The challenge is getting developers and systems programmers to make the move to the mainframe. The advent of modern user interfaces, especially through Eclipse, is making it possible for a new migration of people to the mainframe. Here at Serena we have been long term advocates of what we call “role specific user interfaces”, by which we mean that if you are a developer your needs for interaction with a system are going to be very different than if you’re a tool administrator. Java developers need different tools to COBOL developers. The idea that “one size fits all” satisfies no one.

Today the Serena booth on the expo floor has been busier than ever. We had a huge crowd last night for the prize drawing of a Nexus 7. I expect the crowd to be just as big tonight as we give away another one.

The new ChangeMan SSM 8.4 is wowing every Systems Programmer who takes the test drive. And most are signing up for the free 90-days trial. You can sign up to.

We’re here again tonight until 7:30 pm and you’ll find us at booth #418.

I’m tweeting and following the hash tag #SHAREorg and you can follow me at @SerenaSoftware and @KevinParkerUSA.

Thanks to Tagxedo for help with the word cloud again.

Tags: Serena

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 “verify” – the what you have to do to be sure you deployed correctly
  • The “startup” – what you have to do to bring things back on the air after you have verified that there has been a successful deployment including restarting servers, re-opening telecommunications, resetting log files
  • The “what if” – the steps you need to take if any part of the “set up”, the “verify” or “startup” doesn’t go as predicted

Deployment to multiple targets

Constant inconsistency is consistently predictable

Your application may be simple and confined to a few identical target platforms or it may be n-tiered and deployed to a chaotic topology completely out of your control. Irrespective your deployment will have these 5 elements.

All of these steps are predictable and any variation in the how the steps are executed is determinable. For example if there are no SQL DDL changes in the payload then there’s no need to stop the database. If the web server won’t stop abort the deployment and notify the release engineer.

It might take a release engineer the best part of a day to re-craft a deployment script for each “unique” deployment and even the very best engineers will only have a 99% success rate. If the script executes for an hour every day there will be at least three outages a year and more time spent fixing scripts that actually deploying.

With Serena’s Deployment Automation solution you spend less time developing scripts because the whole process is entirely graphical. You get to reuse elements for deploying to standard environments like Oracle database and the Amazon cloud. You get to spend more time thinking about what to do if the deployment fails and you get to build in all the logic you need so that even the most diverse and complex deployments become commonplace and predictable. Your release engineers spend their time improving and automating and Serena Deployment Automation takes care of everything else.

You can learn more about deployment automation at

Share Monday Cloud

Monday’s buzzwords here at SHARE

It has been pretty hectic here this afternoon at the Serena booth (#418) where we are showcasing the latest version of ChangeMan SSM to the nearly 1,000 attendees. Response has been great and a number of Systems Programmers have taken advantage of the special offer of trying ChangeMan SSM for free for 90-days. You can be part of this great offer too by signing up for the free trial at

This morning’s keynote presentation was very thought provoking and looked at the idea of trying to get the right resources and right technology in the right place in order to sustain the modernization that businesses need in the 21st century. The message was clear, the mainframe is still at the heart of the enterprise and is just as capable of contributing to, and leading in many cases, an organization’s innovation initiatives and it will continue to remain relevant for many decades to come.

Away from the general session there were many topics to choose from and I was drawn to the Big Data and Big Analytics sessions. For more than a decade Serena has been pioneering the delivery of corporate insight from the host to mobile devices. As long ago as 1999 we were alerting Change and Release Managers on their pagers about production deployments and getting their approvals from the web. Now IBM has developed the infrastructure to make that happen with ease and speed for all companies. The recent announcement of an “alliance” between IBM and Apple is proof that the battle is over and the smartphone and smart devices win and that the data battle is over too (in IBM’s view) it will thrive in the corporate data-center on the mainframe.

The expo is winding down right now but we’ll be here until 7:30 pm if you want to stop by booth #418. Also you can track the activities live on Twitter by following the hash tag #SHAREorg and by following @SerenaSoftware and @KevinParkerUSA.

Thanks to Tagxedo for help with the word cloud

5 deployment traps we can’t seem to avoid

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 errors creep in.

Here are five common traps we fall into that are easy to avoid and inexpensive to solve.

1: Every deployment is unique

There’s your whole problem. It is true that what is being deployed is (or at least should be) different each time you deploy but how it is deployed needs to be standardized and familiar so it becomes repeatable and predictable. Each time you update an application it likely that it has the same topology, the same dependencies, the same footprint and the same risks.

2: Every target is unique

This is a common problem too. In the Internet of Things every device on every hip, in every pocket and buried on our phone is a unique configuration of versions and patches and operating systems. Every server has custom settings and distinctive considerations that need to be accommodated. It is beyond any human’s ability to track and manage the discrepancies amongst so many deployment targets. But yet we try with our spreadsheets and notebooks.

3: Emergency fixes are different

On a Sunday morning, at 3:00 am, no one wants to modify the 27 deployment scripts and the 81 server config files or follow the defined procedures to stop the 14 databases and quiesce the 8 transaction queues just to make a simple change. A skilled developer can do what’s need by writing a simple PERL script, right? But on Monday morning, at 8:00 am, no one wants to explain to the CEO why overnight trading in Tokyo and Hong Kong was down either. In many ways emergency fixes have more risk because they are usually developed under pressure, tested less, by pass approval levels and get deployed in whatever way seems quickest. There is too great a temptation (or expectation) to do what is expedient over what it right because the right way is the long way. Yet we all know the automated way is the right way and the fastest (and safest) way.

4: Each deployment needs me

I remember sitting in a meeting room. Outside I could see two developers peering at a screen and nodding their heads up and down in an erratic and random manner. I asked the client what was happening and she explained they were deploying a release and “watching the script go by in case something bad happened.” If a deployment fails many release engineers will roll up their sleeves and start to unpick the changes and the rest will try to fix it on the fly and keep going. This is why deployments need their release engineers to be close during the process. But what are they going to do if the deployment stops (or worse flags and error and doesn’t stop)? They have to find the problem and decide “fix forward” or “backout”? They have to then work out which is best and easiest, quickest, safest to do. If this was built right into the scripts from the beginning they could devote their energies to finding out why it failed and fixing that.

5: Errors happen: its software

There is a sense that errors are inevitable. That something will always get missed and we can correct for that later. If we are agile and iterating in small increments the risks are low and the impact minimal. In our hearts we know that is bogus. One change to one configuration line in a server can stop it from executing and bring our entire system to a halt.


In the next post we will address these issues and look at what is needed to be effective and efficient in deploying software. As this series continues I would welcome your thoughts and experiences. You can add them right here.

Next week: why neither deployments nor target platforms unique.

Well it’s here! The registration for xChange15 in Washington DC opened today. Visit 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 through August 29th, 2014. You can contact me directly at to get your discount code.

Looking forward to seeing you in DC!