Skip to main content

Posts

Showing posts with the label Release Management

Who needs to be informed and knowledgeable about DevOps Test Engineering?

Testing starts with the first line of code!   It is NOT a downstream activity. DevOps testing has a critical role to play in a Continuous Delivery Pipeline. Without integrated testing DevOps simply will not work!   With the advent of DevOps and the movement to breakdown silos between developers, QA, security, and operations, it becomes critically important that all members of an IT team - regardless of what tools they use, or role they play - understand the essentials of testing. Every member of your development team should also integrate to ensure Compliance and Audit outcomes!   It is a new world.   In this new world, we can leverage from existing but must be open to walking through new doors of opportunity. Understanding traditional test strategies is helpful but when and where, and most importantly how we proceed with our test strategy must shift.   Knowing how to code is not enough, Quality Assurance in and of itself is not enough.   We cannot afford to have our products

Process Practitioner Examples – Roles and Responsibilities Revisited

Assigning clearly defined roles and responsibilities are critical to the success of every process. These roles need to be defined early and reviewed periodically to ensure proper training, communication and education.  A process without clearly defined roles will fail at some level.   There is a very clear distinction in the activities or the roles that are played out by individuals in your organization.  You should determine and communicate who is accountable and who is responsible for the process activities.  A role is like a hat.  One individual could wear two or more hats.  Watch out for titles.  You might have a title such as Service Transition Manager.  What role(s) would this individual fulfill? It all depends on WHO is best suited for the role or task that needs to be performed when it comes to assigning roles. The Service Transition Manager could be accountable or OWN the “Release and Deployment” process but might also be a practitioner and be responsible to perform task

What is RCV?

RCV stands for Release, Control and Validate.  These are critical activities that are required for every deployment.  Proper Release, Control and Validation (RCV) is achieved as a result of integrated process activities.  In today's dynamic business climate, service outages cause real bottom line impact to the business. Mature processes are critical in enabling IT organizations to smoothly transition new and changed services into production, helping to ensure stability for IT and the business. The ITIL Capability course, Release, Control and Validation (RCV), provides the best practice process knowledge required to build, test and deploy successful IT services.  RCV is also the name of an ITIL intermediate training and certification. This course provides in-depth knowledge of the ITSM RCV processes that include: Change Management Release and Deployment Management Service Validation and Testing Service Asset and Configuration Management Request Fulfillment Change Evalu

Knowledge Management

Knowledge Management provides value to all stages of the service lifecycle by providing secure accurate and up to date knowledge, information and data that is needed to manage and deliver services. Knowledge Management is particularly important within Service Transition since current and applicable knowledge is one of the key service elements being transitioned.  Effective Knowledge Management is a powerful tool for people in all roles across all stages of the service lifecycle. It is a best practice method for individuals and teams to share data, information and knowledge about all components of an IT service. Having the right information in the right place at the right time will enhance all stake holder’s ability to make informed decisions based on the most current knowledge about their environments. Successful management of data, information and knowledge will enable the service provider staff to have a clear understanding of who uses the services, how they use those servic

Release, Control and Validation (RCV) – Service Management Secret Ingredients

In today's dynamic business climate, service outages cause real bottom line impact to the business. There are documented best practice processes and known critical success factors and yet outages that throw support organizations into reactive firefighting turmoil are far too common. Mature processes with just enough control are needed to smoothly transition new and changed services into production, helping to ensure stability for IT and the business.  Most organizations will confirm that they do have Change and Release Management processes in place.  Service Providers will usually have some level of Service Asset and Configuration Management control.  There is generally a lot of buzz and focus on three core processes for Service Transition and the success and integration of these three are critical to business success.  Three Core Processes for Service Transition are: Change Management Service Asset and Configuration Management Release Management Most IT organizations

Transition Critical Success Factors (CSF’s)

IT is a large and growing slice of the overall budget for many companies. That money spent on IT is anticipated to create business value and support business growth. However in many IT organizations, a considerable percentage of this budget and IT labor is consumed on managing of incidents. First, second and third tier levels of support along with support technology and tools can become expensive to retain and maintain. In fact this is unplanned work which inhibits value creation and business growth. Many people will advocate a solid proactive problem management process to eliminate the root cause of these incidents and I am right there alongside them. However, I think we need to look even earlier in the service lifecycle. The standard statistic that I see most often quoted is that up to 80% of all incidents are cause by undocumented and unauthorized changes.  So for the sake of this argument let us take that as our baseline and discuss critical success factors facing service tran

Service Transition: Release Unit vs Release Package

A “Release Unit” describes the portion of a service or IT infrastructure that is normally released as a single entity according to the organizations release policy. The Release Unit can be thought of as a collection of infrastructure items that when packaged together could perform a useful function. The unit may vary depending on the type or item of service asset or service component.  The actual components to be released on a specific occasion may include one or more release units, or may include only part of a release unit.  Release Units should contain information about the service, its utilities and warranties and release documentation.  These components can be grouped together into a Release Package for a specific release.  In general the aim is to decide the most appropriate release unit level for each service asset or component. A “Release Package” is a set of configuration items that will be built, tested and deployed together as a single release.  Each release will take th

Visible Ops

Anyone who has worked in Information Technology knows that today, there is and always will be improvement opportunities available to our organizations.  This is especially in light of the pace of change that is taking place in all market spaces and the level of customer expectations that accompanies that change. If you have worked in IT for a number of years, you may remember when change was not welcomed. Well the good old days weren’t always that good and tomorrow ain’t as bad as it seems (Billy Joel).  The challenge is in getting started. If……. ·        the processes that are currently being engaged are not as efficient and effective as you would like ·        you are finding that your environment isn’t as stable and reliable as it should be ·        that when you make changes to your environment it generally results in an outage and prolonged and repeatable firefighting then ……. I recommend that you read The Visible Ops Handbook by Gene Kim, Kevin Behr and Geor

The Difference Between Change and Release Management

A reader recently asked me to comment on the difference between Change and Release Management. The first question “is it a request or proposal?” is a good one.  When we use the term proposal, normally we are speaking about major changes that will involve significant risk, cost or organizational impact.  Proposals are normally initiated by the portfolio management process.  They can also be submitted by a program or project management office.  Again remember that each organization is unique and how they do this and at what level it takes place can be different from organization to organization. This is defined at a high level, but the details necessary will depend on the organizational requirements.  For the most part before the new or significantly changed service is chartered it is critical that the proposed change be reviewed for its potential impact on other services, shared resources and the change schedule. These proposals are submitted to change management before being chart

The Value of Release Models

To understand the concept of “Release Models” one must first understand the clear distinction between the Change Management process and the process of Release and Deployment Management.   At a high level you could say that the Change Management process activities assess, authorizes and control the change and that Release and Deployment Process will actually execute or implement the change. This helps to understand the difference between change and release but also to understand that there will be different skillsets and activities involved for each area.    Although Change and Release management processes in and of themselves do have clearly defined objectives, roles and responsibilities these processes do not stand alone and must consistently work together for seamless integration with all of the Service Transition processes including Service Asset and Configuration Management and Validate and Testing processes.   This is especially true when you set out to define “Release Models”

The Difference between Change and Release Management

There is often confusion between the goals, authorities and roles of Change and Release Management.  In fact, the objectives of each of process are very, very different. Change rules! Change Management is an authoritative process that governs anything that potentially impacts a new or existing service.  It is both the enabler of innovation and protector of stability.   It is first and foremost a risk management process.   It is also a planning process.   If Change Management is a governance process, Release Management is an action process.  Under the authority of Change, Release builds, tests and releases new or updated services into the production environment.  Every release is comprised of a single change or package of changes.  Release Management is more technical than Change. If done well, both processes will avoid unnecessary levels of bureaucracy and will build a collection of change and release models that pre-define and pre-approve the rigor required based on levels

VOI and ROI of Release and Deployment Management

I was recently asked about the ROI and VOI of Release and Deployment Management.   Let me start by acknowledging that there is a lot of confusion about the difference between Release and Deployment Management and Change Management.     Change Management is a risk management, governance process.     Release Management is more actionable – it is about bringing one or more changes to life through defined pre and post production activities.    You could almost call it the DevOps process. The growing requirement   for rapid (some would say continuous) deployment does not undermine the need for quality releases.     In fact, a structured approach to rapid deployment is more critical than ever since there is less time to flush out errors.   You can make the process more agile by building release models for different types of releases.   The models can match the rigor associated with building, testing, implementation testing and deployment with the complexity, risk, business n

The Best of Service Transition, Part 3

Early Life Support Originally Published on May 3, 2010 I have found, after doing a number of releases throughout my career, that a solid Early Life Support program (ELS) can really enhance the acceptance and support of any new or changed service. The ITIL Service Transition definition of ELS is the “Support provided for a new or changed IT service for a period of time after it is released." During ELS the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional resources for Incident and Problem Management.   Although stakeholders have agreed to the entry and exit criteria in the Service Design stage, it may become necessary to finalize the performance targets and exit criteria after the build and testing of the service has been completed. This will help to clarify the deployment process and set the proper expectation of the operational resources that will perform the support after ELS has been completed. ELS ensures that ap