Request A Demo
Back to All Blog Articles

Please Release Me

As the well-known lyric goes, ‘Please release me and let me go‘ illustrates the challenge to Application Development and Delivery, though perhaps not in quite the same way as Englebert Humperdinck performed it. In his latest blog, Ash Owen, Senior Product Manager at Flexagon provides his view on the “please release me” challenges of software delivery teams.  

For Development teams that have adopted and achieved consistent velocity of regular software deliveries I still hear the cry ‘please release me’ as they battle to convince their downstream brethren that quality, security and scalability demands for production, be this on-premises or in the cloud, are met. 

For Operations teams that have long maintained and are modernizing and improving the infrastructure to support new and updated business services, I still hear the cry ‘please release me’ but with many provisos from different perspectives. The DBAs who need to assess impact and plan the database changes that need to be promoted to production databases, the network team who must check and validate the scalability, security and performance demands of the new or updated application, the customer success team who, as always, are charged with servicing and supporting requests and reports arising from users or customers, and the business that seeks rapid adoption and increased use as the new business applications and services become available. 

I first came across the release challenge many years ago while conducting an assessment at a large healthcare company. The focus of our assessment was their release process and when I asked for some details, our primary stakeholder (who was responsible for release and service management at the time) departed the room, only to come back with a thick binder detailing the planning and detailed steps involved in their release process. A veritable tome that itself was subject to regular revision and change. 

Opening the binder revealed several spreadsheets, created to reflect the status of the release, and used to report updates to management. These spreadsheets were manually configured, gathering data from various development, QA and infrastructure teams and took an intensive week or so by our primary stakeholder to create and finalize. Given these were weekly reports to executive management, it was clear the effort to build, maintain and update the spreadsheets was not only onerous but continuous and considered a master record of “As-Is” status. 

Beyond the spreadsheets, were reams and reams of paper detailing the complexity of step-by-step deployment instructions, sequenced in order, and in the margin was an assigned role or department who was required to perform that step. The business application in question was the most critical and most significant in this organization’s portfolio, comprising a benefit management system that ran across Mainframe, Mid-range, and Windows platforms, supporting a myriad of supporting algorithms for each state, interfacing back end to point-of-sale. 

When the release was deemed “ready” for production, and I do not mean to minimize the work required to coordinate the complexity of multiple teams to achieve “ready” status, the million-dollar meeting occurred. Typically held over a long weekend, it involved a coordinated step-by-step approach to implementing the release process and production deployment. As you might imagine, stakeholders and owners represented at this meeting included Development, Release, Quality, Security, Network, DBAs, Infrastructure leaders and their supporting teams. Stories were shared of the heroics, long nights, and successful aborts in this coordinated and collaborative but manual release process. We referred to this process at which each functional team was executing their sequenced deployment steps as the million-dollar meeting, and not surprisingly, that was considered an underestimate by everyone present. 

Today we know that in most companies those days are gone. But for things to have changed, several things needed to happen: 

  1. Maintain a prioritized backlog and track through development and delivery 
  2. Version Everything, regardless of platform and associated release BOMs 
  3. Shift Left with Continuous Inspection 
  4. Automate your path to production (environments, testing, deployment) 
  5. Dashboard Everything for a 360 view of the development and delivery pipelines and throughout the value stream 

Adopting these modern practices among development and operations teams will address the waste, time, and effort in maintaining spreadsheets, eliminate those legacy million-dollar meetings and speed the deployment of high-quality releases of new and updated business applications and services. If you are still much closer to the million-dollar release me meetings than your team would like to be, read our guide DevOps for Developers to help you convince executives and stakeholders how to optimize your DevOps practices.  

Related Resources

Oracle Integration Cloud – Migrate Integrations, Connections and Lookups

Oracle Integration Cloud (OIC) serves as a unified platform for seamlessly integrating cloud and on-premises applications. FlexDeploy, a robust DevOps ...
Kintana

Why Kintana Isn’t a Long-Term Viability for Enterprises

Those who have worked in IT for any length of time are likely familiar with the project management tool Kintana. ...

3 Steps to Increasing your Development Release Velocity

Every organization needs to be responsive to changing business needs and market dynamics. While we have seen agile adoption resulting ...

Join DevOps leaders across the globe who receive analysis, tips, and trends in their inbox