Plutora Blog - Release Management
3 Steps to Efficient Enterprise DevOpsReading time 6 minutes
If you work for a large company, you’ll often look around and wonder if moving to a daily release cycle or automating deployments is even possible given the number of meetings and the amount of process your releases are subject to. Between the CAB meetings, the QA schedules, and the coordinated conference calls it’s tough to imagine a monthly release process being condensed down to a process that could run in a single day. For most organizations dealing with real risk – it’s true – you will not be able to condense release cycles down to a single day, but you can get closer to this ideal if you make the right decisions about how your department is organized and managed.
Step 1 – Architect Teams for Independence
One of the real productivity-killers in the enterprise is the presence of monolithic, highly integrated application development groups in the enterprise. Large companies always split up groups of developers into smaller application development teams, but if organizations are not careful about architecture and team structure boundaries between teams can begin to blur and technical dependencies can create highly coupled, monolithic systems. These are 150-200 person teams that are always gated by the lower common denominator.
When your teams are creating new software systems encourage them to engineer systems for as much independence as possible. Teams should be able to release independently, relationships between teams and systems should be focused and well-documented, and testing and verification during a software release shouldn’t require a conference call with 60 people just to make sure systems are up and running. If you can achieve operational independence in production between two systems, this is preferable than building a direct dependency between two systems.
The DevOps you read about in industry magazines and blogs focuses on team-level benefits of deployment automation, continuous software delivery, and greater ownership of operations by developers. If your systems turn into a single, high-risk monolith every release will involve hundreds of developers and the organization’s sprint toward agility will be limited by the number of meetings and conference calls required to implement even the simplest of changes.
Step 2 – Provide Strong Orchestration
You can’t just tell your teams to “devops” and be done with it. Instead, you need to stand up a strong and centralized release management function to ensure that someone is tracking cross-project conflicts and assessing overall risk. If teams are going to move independent of one another and release more frequently someone needs to be in charge of your department’s “airspace.” In this way the senior release manager becomes the critical resource to enable Enterprise DevOps. Strong orchestration enables greater agility.
As your now-independent teams embrace Agile software development and as application developers become more productive your release managers will have a greater responsibility to look ahead and plan for a new, multi-project release schedule. In the “Old Enterprise” when systems were highly coupled and monolithic it was impossible for teams to deliver on different schedules. With deployment automation and continuous software delivery you may have teams that are ready to deliver every single day alongside teams that are only prepared to deliver once a month. Release managers will often be required to step in to bridge the difference between teams that have adopted DevOps practices and teams unable to adapt to a more agile approach.
In Enterprise DevOps it is the release managers that become the most important management function in IT. Prior to the advent of DevOps a release manager could create arbitrary monthly releases and manage every project in a single, monolithic release process. With the agility, independence, and greater release frequency that accompanies Enterprise DevOps, release managers become the referees for a busy schedule of daily releases.
Step 3 – Standardize Environments
Most large enterprises can’t use public clouds… yet. These efficient, “friction-less” environments available on a Rackspace or AWS must be approximated with internal clouds based on technologies like VMware or OpenStack. With sensitive data and databases requiring the highest levels of performance physical infrastructure may be required. Given these limitations your IT department needs to create a standard approach to the application environment lifecycle for independent teams.
Your department might take significantly longer to make a successful transition to DevOps in the enterprise if each independent team chooses a different deployment automation technology and technology stack. Providing teams with a standard approach to both platform architecture and cloud-based deployment technology will make it possible for teams to deliver software without creating an operational burden for teams and an impossible situation for your environment managers.
To foster agility you should provide all teams with a standard set of deployment automation tools and supported architectures. You should empower your environment managers to establish common standards, and you should expect yoru development teams to fully automate the creation and destruction of environments on public or private cloud-based infrastructure. Independent, strongly-orchestrated teams should be able to deploy and redeploy QA and staging systems at a moment’s notice with the help of a department-wide environment management system.
Enterprise DevOps Requires Structure
While “popular DevOps” emphasizes team-level innovation without obstacles in an environment free of process, “Enterprise DevOps” requires a commitment to strong governance. Making DevOps work in the enterprise requires the creation of intelligent governance structures to protect teams from the debilitating gridlock of highly coupled systems. Success adopters of Enterprise DevOps provide department level awareness to release managers and environment managers to mitigate the risk of resource and release contention.
By designing your groups to be independent and providing your release and environment managers with the right tools you can foster greater agility and more operational ownership across your development teams. Plutora’s products are designed to help with Steps #2 and #3. Plutora Release Manager and Plutora Environment Manager were designed to help companies adopt a standard, overall approach to IT governance while fostering a sense of independence among individual application teams.