How to manage your environments, going from Development (DEV) to Production (PRD) with Management Packs.

Question

I am looking for a way to go from the development (DEV) environment to the production (PRD) environment in a controlled manner.
As I do not want to manually click around with a walk-through screen-shots document = error prone.
As I read these articles
http://technet.microsoft.com/en-us/library/hh519659.aspx
http://blogs.technet.com/b/antoni/archive/2013/10/09/system-center-service-manager-operations-manager-management-pack-and-naming-convention-best-practices.aspx
http://blogs.technet.com/b/wincat/archive/2013/03/28/copying-user-roles-between-management-servers-in-service-manager-2012.aspx
http://www.netiviaconsulting.com/2012/05/10/staying-organized-with-scsm-beware-of-the-management-pack-jungle/
I still have some questions:
1. Can all MPs (un-sealed) be exported from DEV and imported to PRD without breaking things?
2. Are there any known pitfalls?
3. Do you have some tips on this matter? In other words, how do you manage this?
Regards,
Erik

Answer 1

Alex is spot-on. Most MPs are environment/management group independent.
But some MPs contain what I call "Environment Specific Variables". In my experience, ESVs are in:
1) Templates (such as the runbook guids)
2) Criteria blocks (like view criteria, and rule criteria)
3) Parameters (such as write action parameters, and console task parameters)
Alex already gave an example of a template ESV.
An example of a Criteria ESV might be some view that you developed that returns objects that have a specific set of values in your dev environment, but may be different for your prod environment. ie: You have a view whose criteria looks afor a specific business
service ServiceId property. Let's say "Business Service X". But "Business Service X" has a different ServiceId in your dev environment than in your prod environment. So, every time you import your view MP from dev to prod, you have to remember to change your
criteria.
A quick Parameter ESV example; you have a notification subscription (a rule+writeaction). In Dev, you've hardcoded the notification recipient to be yourself. In Prod, the recipient has to be your boss. So, every time you import your MP from Dev to Prod,
you have to remember to change the recipient parameter in the subscription's writeaction.
Like Alex said, handling ESVs by hand is error-prone and time consuming.
Alex, when you write that utility, you should make it more robust. Within an MP, allow a user to pick and configure
any ESV. Store that configuration. Then, just run the MP through the utility and have it automatically set all the configured ESVs to the appropriate environment specific value :) (It's been something I've wanted to write into TFS for
a while, but I never take the time to do it ;) ) If an ESV is missing (because it was removed or changed in such a way that it no longer resembles the configured ESV), throw a warning during conversion.