- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2023 09:04 AM
Hi everyone,
I'm looking for insights and experiences on how to improve our way of developing to be more aligned with the DevOps philosophy. The majority of our team is still working with update sets while a part of the team (CMDB) started their development with the Azure DevOps integration. That proved to be a great way of working but we are struggling to expand it to the more core ITSM stuff that we are building/changing.
It is quite clear that CMDB can have multiple applications:
- Global application for commonalities
- Scoped applications for specific integrations
We are struggling to translate this to the general parts of the platform (change management, case management, incident management, SLAs, ACLs etc.)?
Should we have:
- multiple global applications with pipelines where we capture those changes?
- One global application for all core ITSM things? I see challenges with multiple people working on it.
From what I read I see a big push from ServiceNow towards a more DevOps way of working rather than sticking with update sets but there is little guidance on this topic. An additional issue is that you cannot work on everything from Studio which complicates capturing certain updates.
What are your experiences working with DevOps in ServiceNow? How do you organize your applications? I would love to start a discussion to see what the community is doing on this topic or what ServiceNow currently recommends.
Solved! Go to Solution.
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-28-2023 12:50 PM
That white paper is outdated. I have attached the new one that explains and expands in greater detail.
I also attached one that goes over developing in the Global Scope.
Development Deployment Management on SN has many moving parts, so it is hard to say one size fits all.
It might not answer your question. Hopefully, it provides more context to help come up with a solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-18-2023 01:29 PM
I am trying to wrap my head around the same thing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2023 01:55 AM
Did you find any good resources on this topic?
This whitepaper made us look into this. The latest update encourages the transition from update sets to this way of working.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2023 02:17 AM
Did you find any good resources on this topic?
This whitepaper made us look into this. The latest update encourages the transition from update sets to this way of working.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2023 07:32 AM
Hi Jan,
Unfortunately nothing groundbreaking. I know that global scoped apps are capturable easily as of Paris according to this doc: https://developer.servicenow.com/blog.do?p=/post/paris-source-control/
But like you said there's still complications for non-scoped applications. Looking at how the new Upgrade Plan application functions, I'm not too hopeful that there really is a good solution out there. Essentially what it does is create a mirror scoped application for the global scope and then migrates many files that are in the actual global scope to this pseudo global scope app. It then moves those changes across from one environment to another by migrating the pseudo global scoped app. And the fun part is that now you have two scopes to manage, the original Global scope and then pseudo one.
I have seen certain folks build a full solution using things like Instance Scan and some of the DevOps integration components with Update Sets, but nothing really seemed like it was the "recommended" way to do it. It was more of a hack.
