Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Stackify Blog, Jnan Dash, Liz McMillan, Janakiram MSV

Related Topics: @DevOpsSummit, Microservices Expo, @CloudExpo

@DevOpsSummit: Blog Feed Post

Release Management Risk By @DaliborSiroky | @DevOpsSummit [#DevOps]

Here are a few questions to help you assess the scope of your release management challenges

What’s Your Release Management Risk Factor? In Five Questions

By Dalibor Siroky

Here are a few questions to help you assess the scope of your release management challenges. Based on the answers to these questions, you can calculate your Release Management risk factor.  This will help you understand what steps you need to take today to mitigate release management risks that accompany software development at scale.

Release Management Risk Assessment Questions

____ (Y/N) Question 1. Does your organization have more than 100 IT staff managing more than 25 systems?

These 100 people don't have to be in a single group and the systems maintained don't have to be limited to a single group. Also, note that the systems supported can span a range of customer-facing to back-office solutions - everything from a component of a large website to an email system.

Think about the organization you work for. If there are 100 or more IT employees and 25 or more systems being supported answer Yes to this question.

____ (Y/N) Question 2. Are you under pressure to increase your release cadence and scope?

Release and environment managers across the industry are under pressure to support larger, more varied IT portfolios that call for more frequent releases each of a larger scope.

If your organization has either transitioned or wants to transition from quarterly to monthly or weekly releases answer Yes to this question.

____ (Y/N) Question 3. Are your applications increasingly interdependent with single releases affecting many systems?

First came service-oriented architecture (SOA) and now systems communicate using light-weight REST APIs. The trend in the industry is to build enterprise-scale systems using smaller, independent and more focused components.

If you've been asked to account for cross-application interdependencies in your releases answer Yes to this question.

____ (Y/N) Question 4. Are your delivery teams distributed across geographies or outsourced to partners in different organizations?

On a large team, it's easy to lose track of who is working from where and when they work. If you are often unsure of which office or which timezone members of your team are working in answer Yes to this question. If your team is large it may also be difficult to tell the difference between outsourced projects and internal projects. If this is the case answer Yes to this question.

____ (Y/N) Question 5. Does your release and test environment information exist in disparate silos that are not easily accessible or are out of date?

A universal question in any release process is, "Did you test the application against production data?". Often the answer is unsatisfactory because it is either impossible to get a copy of production data into a QA environment or your organization faces strict security protocols that require labor-intensive data masking activities.

If your release processes rely on several independent applications to work across several different environments and if environment management and orchestration is a challenge answer Yes to this question.

After you've answered these questions count the number of questions answered in the affirmative. This is your Release Management Risk Factor.

____ (Add up the # of Yes Answers) = Your Release Management Risk Factor

Interpreting Your Release Management Risk Factor

Now that you've answered these questions, it is time to evaluate your risk factor.

Risk Factor 0-1 - You are doing just fine and you can manage the low level of risk you are exposed to.

If you answered yes to only 1 question you are operating within a simple IT landscape where releases are relatively straightforward and low risk. Even if you have a large team, your releases are infrequent and low-risk or maybe you have frequent releases, but your application is simple and focused on only a handful of easily managed dependencies.

You are lucky to work in an environment that isn't dominated by release management risk. At a time when IT portfolios are expanding and companies are scaling software development teams to the limit, your releases are easy. Have fun.

Risk Factor 2-3 - Your teams are beginning to feel the strain of multiple complicating factors and "cracks" are beginning to appear in your release process.

Your applications and your personnel are increasingly distributed. As your organization continues to scale and application teams grow, risks associated with release management often outpace an organization's ability to adapt.  Release orchestration activities start to dominate a department dealing with parallel development streams and increasingly interdependent applications.

At this level of risk, the best tool to address developing complexity is information. With Plutora, you can start to assess the impact of releases on your overall timeline. You can see how efficient your teams are at delivering software and supporting software releases and you can use this information to make better decisions about staffing and scheduling.

Risk Factor 4-5 - You are AT RISK OF RELEASE FAILURE. If you answered YES to 4 or 5 questions your organization and IT landscape is highly complex and you need robust processes and solutions in place to control this risk.

Operating at this risk level without a solution dedicated to supporting releases, environments, and deployments isn't easy. You have teams of project managers working on manual spreadsheets tracking release dates, resources, and staffing concerns in a series of endless meetings focused on managing risks.

At this high level of risk, you and your management lack the ability to predict which portions of a complex release schedule are prone to failure and your inefficient, reactive approach to software development is causing delays. Your teams can't deliver on a quarterly or annual development plan because release management issues make it impossible to plan for more than a week.

You need an Enterprise Release Management solution like Plutora so that you spend less time on release administration, reduce risk and accelerate enterprise software delivery.

The post What’s Your Release Management Risk Factor? in 5 Questions appeared first on Plutora Inc.

More Stories By Plutora Blog

Plutora provides Enterprise Release and Test Environment Management SaaS solutions aligning process, technology, and information to solve release orchestration challenges for the enterprise.

Plutora’s SaaS solution enables organizations to model release management and test environment management activities as a bridge between agile project teams and an enterprise’s ITSM initiatives. Using Plutora, you can orchestrate parallel releases from several independent DevOps groups all while giving your executives as well as change management specialists insight into overall risk.

Supporting the largest releases for the largest organizations throughout North America, EMEA, and Asia Pacific, Plutora provides proof that large companies can adopt DevOps while managing the risks that come with wider adoption of self-service and agile software development in the enterprise. Aligning process, technology, and information to solve increasingly complex release orchestration challenges, this Gartner “Cool Vendor in IT DevOps” upgrades the enterprise release management from spreadsheets, meetings, and email to an integrated dashboard giving release managers insight and control over large software releases.

@DevOpsSummit Stories
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
Docker is sweeping across startups and enterprises alike, changing the way we build and ship applications. It's the most prominent and widely known software container platform, and it's particularly useful for eliminating common challenges when collaborating on code (like the "it works on my machine" phenomenon that most devs know all too well). With Docker, you can run and manage apps side-by-side - in isolated containers - resulting in better compute density. It's something that many developers don't think about, but you can even use Docker with ASP.NET.
If you are part of the cloud development community, you certainly know about “serverless computing,” almost a misnomer. Because it implies there are no servers which is untrue. However the servers are hidden from the developers. This model eliminates operational complexity and increases developer productivity. We came from monolithic computing to client-server to services to microservices to the serverless model. In other words, our systems have slowly “dissolved” from monolithic to function-by-function. Software is developed and deployed as individual functions – a first-class object and cloud runs it for you. These functions are triggered by events that follow certain rules. Functions are written in a fixed set of languages, with a fixed set of programming models and cloud-specific syntax and semantics. Cloud-specific services can be invoked to perform complex tasks. So for cloud-na...
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework. It's clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. That means serverless is also changing the way we leverage public clouds. Truth-be-told, many enterprise IT shops were so happy to get out of the management of physical servers within a data center that many limitations of the existing public IaaS clouds were forgiven. However, now that we've lived a few years with public IaaS clouds, developers and CloudOps pros are giving a huge thumbs down to the...
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex to learn. This is because Kubernetes is more of a toolset than a ready solution. Hence it’s essential to know when and how to apply the appropriate Kubernetes constructs.