Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: RBland
New Today: 14
New Yesterday: 86
Overall: 139279

People Online:
Visitors: 60
Members: 0
Total: 60

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Release Management, Release Policy, & QA
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Release Management, Release Policy, & QA

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
Anne
Newbie
Newbie


Joined: Dec 29, 2006
Posts: 1
Location: Pittsburgh, PA

PostPosted: Sat Dec 30, 2006 6:35 am    Post subject: Release Management, Release Policy, & QA Reply with quote

We are implementing ITIL and have had pieces of the framework in place for a while now. We are beginning to implement Release Management. I have two areas within that topic that I need help with.

1) Has anyone created a Release Policy from scratch? If so, any and all insight would be most welcome.

2) If you don't have a QA organization and are trying to create one in a rather slim organizational structure, where do you recommend QA being housed to keep it unbiased? Ideally, QA is not held within Development as a check and balance. Is it appropriate to house the functions under RM?

One thing I find most frustrating about ITIL is that it leaves the area of RM very vague.

Thanks in advance,
Anne
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun Dec 31, 2006 12:12 pm    Post subject: Re: Release Management, Release Policy, & QA Reply with quote

Hello Anne,

Please find my comments to both of your recommendations, below...

Quote:
1) Has anyone created a Release Policy from scratch? If so, any and all insight would be most welcome.


On the topic of implementing Release Management, I guess I'd start with a question: "Are you looking to implement RM for Infrastructure teams, Software Development teams, or both?" I ask this because most people following ITIL will try to implement it for infrastructure and totally forget SW. I recommend implementing it for both.

The first thing you have to get everyone on the same page about is what a Release is and represents. In an enterprise, you have many Products. Every product has a version or, what many will term as a "Release". Therefore, a Release represents a "version" of a Product.

Therefore, Release Management, when done properly, is the management of a Product version or Release from its inception to its final rollout. This should include ever build and every deployment in every environment (development, systems integration testing, user acceptance testing, production, etc.).

ITIL leaves out a tremendous amount in the definition of Release Management and if you try and follow ITIL and only ITIL you will back your enterprise into an ugly corner that you can't get out of. To do it correctly, you will need to understand how SW teams perform Release Management.

At some point a Product Management team decides that it's time to create a new Release or version that they want to take to market. This new Release will address many "drivers" for the release. Typically, these drivers are:

- Requirements (new feature requests and/or enhancements)
- Problems (in the form of defects/bugs)
- Risks (work necessary to avoid future Incidents)

The implementation of these drivers is usually through "Changes" to the Product. Those Changes are usually to the "previous Release" which acts as a baseline for the new Release. So, for example, if Release 2.3.5 is in Production, it will usually become the baseline for a new Release, let's say 2.4.0, which is intended to make it out to Production at some future date.

The Release Management function (typically performed through a role called the Release Manager) will work with teams to address wich Problems, Requirements, and Risks will be addressed in the new Release and will also work with the Development Manager and Product Manager (at a minimum) to come up with an acceptable "Release Schedule".

The Release Schedule, will include "Releases" (or Deployments/Distributions) to each and every environment, for testing, as well as Production rollout. The Release Schedule will include build and packaging info for each environment, testing/verification for each environment, etc. It's simple a grand project plan that is focused on the milestones and deliverables of a "Release" as a project.

The dates that you use to schedule the Release deployment to each environment will help you create your "Forward Schedule of Releases", since all Releases of all Products will show up on this FSR.

NOTE: And this is very critical to understand... A "Release" is a group of one or more "Changes". Therefore, "a Release is one big Change", as far as your Change Management group will be concerned. This is where Infrastructure teams and SW development teams have some difference. SW development teams have been disciplined, over the years, to "group" their changes into controlled master Releases, all focusing around formal Product Management processes. Infrastructure teams, following ITIL, do not follow formal "Product Management" processes and therefore just rollout individual Changes, with no concern, whatsoever, as to which Product it's associated with and what new version of the Product is being derived by the applicaiton of such a Change.

This is where you will run into a huge inconsistency issue between SW dev and infrastructure and engineering. ITIL has taught Infrastructure and Engineering (incorrectly, I might add) to ignore formal "Product Management" processes, which force controlled Release Management processes. ITIL goes right to the granular Change and jumps over the Release. In order to implement Release Management, properly, you will need to overcome this by making the Infrastructure and Engineering teams think in terms of "Products" and version them, appropriately, (i.e. create Releases) when they plan to make Changes to their Products.

An advanced word of warning... Most infrasturcture and engineering teams will fight, tooth and nail, to avoid having that much process and discipline forced on them, even though it really is the right thing to do. Most software teams, on the other hand, have already been conditioned to follow such a disciplined approach. The reason for this is that when building and deploying software, there can very easily be thousands to hundreds of thousands of dependencies that must be controlled to rebuild and redeploy the software to each targeted environment. They can't afford mistakes.

Anyhow, if you really want to do Release Management, properly, I first recommend you get "all" your teams thinking in terms of Products and Product Management, where every Product in your enterprise is owned by someone and has a formally accountable person and/or team that is responsible for it's vision and strategy, throughout it's entire "lifecycle" in your enterprise. Once you have these accountable roles, then each team needs to understand how to plan for and manage "Releases" or version of each and every Product.

As for the role of a Releases Manager, consider it to be a "role" and does not need to be a separate dedicated human unless you really have a large enough Product and/or Release that it would warrant a separate and dedicated human for the role.

When done correctly, Release Management will help plan, coordinate, and execute everything that is necessary for a specific Product Release.

Quote:
2) If you don't have a QA organization and are trying to create one in a rather slim organizational structure, where do you recommend QA being housed to keep it unbiased? Ideally, QA is not held within Development as a check and balance. Is it appropriate to house the functions under RM?


Implementing a QA organization is a bit vague and shaky, as putting a good one in place will require a tremendous amount of dedication, backing, and process around it.

Let me ask you, are you planning to put a QA organization in for SW testing, Infrastructure/Engineering testing, or both?

If you look at the progression of a "Release" through its lifecycle, you will see that the Release needs to be constructed, deployed, instantiated, executed, and verified/tested in "every" environment, from dev all the way out to production. The first question you will have to answer is: "What will be your standard environments for all teams? My recommendation (at a minimum) would be:

- Workspace (Private environment for each developer/engineer)
- Common Development (Common build environment for the merging of work that comes from each developer/engineer).
- Systems Integration Testing (Where you can start to do some high level testing to see how the build interacts with critical components and systems it will rely on or that rely on it)
- User Acceptance Testing (Where you can do things like Performance Testing, Load Testing, Functional Testing of all features and fixes)
- Production (which can mean two things: In-house production environment or a targeted build to burn your media for distribution to market)

Now, given that you have your environments, QA would probably fit into the "User Acceptance Testing" environment, which is the step before your release to your Production environment.

Some things to consider, when implementing a QA team/function:

  • It's usually very difficult to come up with a justified ROI for QA teams. Leadership either believes in them or not.
  • A good reason for a centralized QA team is when you have "many" different development and engineering teams that require the same repeatable set of services for advanced testing.
  • Centralized QA groups will often represent "bottlenecks" for many teams who have to schedule and queue their Product Releases for testing.
  • If a QA team is not empowered to "reject" a Product Release it is virtually worthless, because Product teams will steamroll right through it to get out to their Production environment and meet their dates.
  • Having a centralized QA team will require that "all" teams follow strict and highly repeatable Product Development, Build, Deployment, Installation, Instantiation, Execution, and Verification steps. Very few enterprises are disciplined and/or experienced enough to make this happen.
  • A cetralized QA team will need a significant startup and yearo-over-year investment to stay useful.
  • Core decisions as to what should or shouldn't be tested by the QA team are critical.
  • A good centralized QA team will require that Product teams automate as much of their testing as possible, to that tests are truly repeatable and useful.
  • A good QA team will gather and maintain regular testing metrics and statistics that prove their usefulness.
  • A good QA team will understand solid Product Management principles and the trade-off between things like costs, quality, service, and "time-to-market".


As for which group the QA team should report into, I don't know enough about how your existing enterprise is structured to give you an answer for that. Believe it or not but, in most enterprises, the QA team "does" report to the head of development. Remember, QA is a function that all teams have to do, to some extent, for each and every product. A good development leader understands the repeatable development functions:

- Design
- Implementation/Building/Packaging
- Deployement/Distribution
- Installation
- Instantiation & Initialization
- Execution
- Rollback
- Etc.

If you're doing development and engineering correctly, you're "verifying" after each and every one of these steps...

- Design Verification & Reviews (sometimes through simulation & emulation)
- Implementation/Build/Packaging Verification & Testing
- Deployment/Distribution Verification
- Installation Verification
- Instantiation & Initialization Verification
- Execution Verification
- Rollback Verification
- Etc.

Proper "Testing" is done at every step, in every environment. So, if you're going to centralize QA, the question becomes "What form of testing and verification, exactly, are you centralizing?" I, personally, would be far more concerned with all of the above than "who" QA reports into. To me, it's far more important to get the definition and implementation of QA right. To do that, the baseline "Product Lifecycle/Product Management" processes should be in place, first, as a foundation.

Quote:
One thing I find most frustrating about ITIL is that it leaves the area of RM very vague.


This is because ITIL was created by people who traditionally only think "infrastructure" and not software. Release Management, when done properly, is a very big task that is "Product Management" centric. ITIL represents only a very small piece of the big picture, which is the back-end Production operations portion of the equation. If you want to run IT like a business, you have to look at it from a much larger perspective, which includes "everything" that you do to create, modify, deploy, support, upgrade, and maintain "product".

Anyhow, I hope this helps. I honestly can't give you everything, simply because it's a very big space. But, if you want want to discuss things in further detail, you can always contact me offline at "Frank.Guerino<@>TraverseIT.com".

Best Regards and a Happy New Year!

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.