Is there any documented best practice for version control of Portal\SCSM artifacts?

Gary_Herber

Is there any documented best practices for version control of Portal\SCSM\Orchestrator artifacts such as management packs, configuration files, templates and the like?

Justin_Workman

@Gary_Herber - I don't think there's a documented "best practice".  MPs have versioning built in so I think it makes sense to leverage that. For runbooks, I've seen numbering systems to keep them alphabetically organized.  I've also seen similar approaches for Request Offerings.  I don't think that speaks to 'versioning' specifically though.  I would recommend using the description field in SCSM for keeping that kind of info at least where it's not exposed to end users.  For example, in my User Roles I use the description field like this:

That helps me keep them straight when I'm troubleshooting permissions across the various roles.  I realize this also doesn't speak to versioning, but it's a suggestion on where some of that kind of data can live.  I hope this helps!

Tom_Hendricks

TFS can be helpful for this, particularly if your custom MPs are created in VSAE.  If not, you can copy them to source control manually, with or without an associated project.  If doing the latter, using Git repos in TFS may be more to your liking than the traditional TFS soultions/projects.

Rolling back to an earlier version of an MP is not always simple, but it is nice to have the option if you find yourself with a compelling reason to do so.  It is also helpful to have the older versions available for comparison to newer versions, sometimes, just to see what has changed.

Justin_Workman

@Gary_Herber - I don't think there's a documented "best practice".  MPs have versioning built in so I think it makes sense to leverage that. For runbooks, I've seen numbering systems to keep them alphabetically organized.  I've also seen similar approaches for Request Offerings.  I don't think that speaks to 'versioning' specifically though.  I would recommend using the description field in SCSM for keeping that kind of info at least where it's not exposed to end users.  For example, in my User Roles I use the description field like this:

That helps me keep them straight when I'm troubleshooting permissions across the various roles.  I realize this also doesn't speak to versioning, but it's a suggestion on where some of that kind of data can live.  I hope this helps!

Tom_Hendricks

TFS can be helpful for this, particularly if your custom MPs are created in VSAE.  If not, you can copy them to source control manually, with or without an associated project.  If doing the latter, using Git repos in TFS may be more to your liking than the traditional TFS soultions/projects.

Rolling back to an earlier version of an MP is not always simple, but it is nice to have the option if you find yourself with a compelling reason to do so.  It is also helpful to have the older versions available for comparison to newer versions, sometimes, just to see what has changed.