Every year there are ton of examples illustrating that we still have a lot of work to do. Whether it’s shutting down the Russian stock market for a couple of hours, deploying
Once the developer checks in a change, how long does it take your organization to deliver it to the customer? The path to production can take many turns, have many dips, and fall short in terms of quality and expectations. IT organizations struggle with major process and toolchain gaps between develop, build, deploy, and release. Come join us at the December Serena DevOps Drive-in as Julian
How does a developer know when they are done?. How does a business know that their new application or feature does what the customer wants it to do? By testing. Testing is a cross functional activity that involves the whole team and should be done continuously from the beginning of the project. It serves as the gauntlet that a committed change has to run and pass in order to be considered worthy for release. While testing is a major key ingredient
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.
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
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
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
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