Scribd
Upload
37 views

Ad Release

The document discusses the history and evolution of release management practices. It notes that historically, software changes were released with little control or coordination. Over time, organizations introduced basic controls like test environments and maintenance windows. Today, most organizations follow formal release management processes, but still face challenges of coordination between development and operations teams and managing changes in complex production environments. Further improvements are still needed to release management practices.

Uploaded by

sharatgupta
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
37 views

Ad Release

The document discusses the history and evolution of release management practices. It notes that historically, software changes were released with little control or coordination. Over time, organizations introduced basic controls like test environments and maintenance windows. Today, most organizations follow formal release management processes, but still face challenges of coordination between development and operations teams and managing changes in complex production environments. Further improvements are still needed to release management practices.

Uploaded by

sharatgupta
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

ABSTRACT

Forrester defines Release Management as, “The definition, support, and


enforcement of processes for preparing software for deployment to production.”[1] While we
may recognize the discipline now, Release Management hasn’t always been recognized within
AD and IT Operations.

Back when businesses were first investing in computers and software, Release Management
was more akin to Release Free-for-all. Coders could push changes into production at any time
without any approvals, and without giving notice to stakeholders. After a few failures the
business insisted on some changes. They invested in test machines and maintenance windows,
forcing some discipline into the release process.

We’ve come a long way since then. Today, both AD and IT Ops employ some form of Release
Management. In AD Release Management happens at the tail end of a formal Applications
Lifecycle Management (ALM) process. IT Operations has widely accepted the IT Infrastructure
Library (ITIL) framework to impose accountability and control over the production environment.
We also have separation of duties so business representatives decide what we are to build,
developers to build, and QA to determine whether the software works. In most organizations
today there is at least some control over software changes put into production.

Even with these advances, we continue to have problems. There is growing distrust between
AD and IT Ops as their goals and expected performance measures are more and more at odds.
There is often no well-defined process for managing the hand-off between AD and IT
Operations, causing confusion about what changes should be made to the production
environment. And even while we have put controls in place to manage the production
environment, that environment has become much more complex and chaotic While better than
the chaos of the past, our current Release Management practices need further improvement.
EXISTING SYSTEM:

We just set up Subversion and we're in the process of trying to set up a release
management process. It will follow the Dev -> Stage -> Production model. We're stuck on
how to make this model work using Subversion's repository based versioning system.

You might also like