Release management is often not seen by young software developers as an attractive field to enter. In reality, though, it’s an exciting, fast-paced, and constantly evolving area that is integral to the success of a product! Our panelists delved into what makes the role of the release manager, and the more technical role of release engineer, so unique.
Release engineers have to wear lots of hats all the time: be a developer, release engineer, and site operator. Which means you have to know the code, know what it takes to get the code out safely and troubleshoot production issues. ~Eugene Boguslavsky, Facebook
Release engineers have to wear lots of hats all the time: be a developer, release engineer, and site operator. Which means you have to know the code, know what it takes to get the code out safely and troubleshoot production issues.
Eugene Boguslavsky, Facebook
I think that Release Engineer / DevOps is one of the most challenging positions in Software. A good Release Engineer understands the whole application / UI, database, code. They look at the code, they know the database, they know how to build and deploy it and even test it. A good Release Engineer can pinpoint a problem very quickly and know if it is configuration or code issue. They need to be a fast learner — picking up on new technology without being intimidated. This person needs to be patient and have excellent communication skills to get along with many different personalities. It is a very challenging but rewarding role.
Rachna Mahajan, Workday
Salesforce blazed the trail of Software as a Service (SaaS), which is effectively deploying the same changes to all customers and partners. With over 30 years of experience in the software industry, I have seen a dramatic shift in the way companies approach releasing software.
The Release Deployment Model (RDM) used to be equated to landing a large jetliner on time. You had to meet a set schedule to make a large delivery, and your vessel had a fixed capacity. The process and tools were maintained statically by a team of experts who followed a highly formalized process.
But now, deploying a software release is more like a set of drones landing with precision, as needed. Smaller deliveries are made more frequently, and consumed when they are needed. Capacity is elastic, and there is self-mediated, autonomous maintenance. Delivery is smarter, and consumers of the releases can select when they want the changes delivered.
At Facebook, they require all engineers to wear a dev-ops hat and dev-ops employees to wear an engineering hat. “You can’t just land code and hope someone else is going to test it. You land, test, ship your own code and monitor it in production,” Eugene said.
So what do companies have to do to ensure their software is released with an ever-quickening timeline to an ever-increasing scale of distributed target systems: computers, mobile devices, and connected devices?
When serving a diverse set of consumer or corporate customers, there will be a very wide spectrum of opinions about the frequency, content, timing and risk tolerance of releases. Whenever you are introducing change through a software release, there are actions that have to be done by ISVs, partners, system admins, and end-users to work with the new change. SaaS was a revolutionary new way of delivering changes and updates to a range of customers all at once, but now a new question has emerged: can we provide more control for the consumers of the Web-based software so they can schedule when they want to consume changes as they used to before Cloud SaaS? And how much control do companies and mobile users have over the releases to the mobile tier? How do connected, everyday devices get software updates?
New platforms and devices are rapidly emerging that demand new approaches to delivering the software that runs on them. Continuous delivery has reduced the number of steps between change and release. That impacts the release engineer’s role. Releasing software is all about managing the changes moving from an internal test or staging environment to a live, production environment. All releases should be boring in terms of moving the content from an internal environment to an external one. How you achieve that boring event, with as little human involvement as possible and at a huge scale, is open to a lot of debate, but all of our panelists agreed that removing humans from the process and having as much automation as possible is extremely important.
There are immense, interesting challenges faced by our companies to release software without any negative impact to users. Our hope in discussing these on the panel was that the audience would leave excited about all the considerations for releasing software and the tradeoffs that have to be faced, not to mention the Internet of Things and how all of the connected devices that consumers are interacting with, have a software component that is being released in the Cloud.
Sound interesting? Check out all of our open positions in Release Management, including summer internships, and follow us on Twitter and Instagram to see what’s behind the cloud.
