Versioning and Development Coordination
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago - last edited 4 hours ago
Hello everyone,
As someone coming from a computer science background, I sometimes find it difficult to give credit to Update Sets and custom applications in ServiceNow. Although they have their limitations, they are a core part of the ServiceNow ecosystem and therefore deserve a clear and well-defined development strategy.
Over time, I have seen different approaches to versioning and deployment management. Some worked reasonably well, while others became a significant burden as teams and applications grew. This made me curious about how other teams approach these challenges.
In my experience, the chosen versioning strategy has a direct impact on development coordination. The easier it is to understand what is being developed, released, and maintained, the easier it becomes to coordinate parallel work, avoid collisions, and deploy changes safely.
I'd therefore like to hear about both your versioning approach and how you manage visibility into ongoing development.
1. What versioning strategy do you think is the most effective?
- Scoped Applications with Git Integration
- Update Sets only
- Scoped Applications only
- Hybrid approach (Applications + Update Sets)
- Release-based versioning
- CI/CD-driven versioning
- Other (please explain)
2. What is the best way to make ongoing development visible and avoid collisions (e.g. multiple developers working in the same application)?
- Runbook
- Shared documentation (Confluence, SharePoint, Wiki, etc.)
- Agile/Kanban Board (Jira, Azure DevOps, ServiceNow Agile, etc.)
- Custom ServiceNow table or development registry
- Git branches and pull requests
- Application/component ownership model
- Regular developer sync meetings
- Combination of multiple approaches
- Other (please explain)
I'm particularly interested in understanding what your team's source of truth is for active development and how you balance flexibility with deployment safety.
Looking forward to hearing about your experiences and lessons learned.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
Hi @martinfaehn
1)For modern ServiceNow development, I find a hybrid approach to be the most effective.
- Update Sets continue to play an important role for global changes and other artifacts that cannot be managed through application repositories.
- Scoped Applications provide structured versioning and packaging, while Git integration enables source control, branching, code reviews, and end-to-end traceability.
2)
- Update set is having Version tab where who has worked last/updated code &when ,everything are captured.
- Git also provides version history, code reviews, and traceability.
- In addition, regular team sync meetings ensure everyone has visibility into ongoing work, discuss dependencies, and identify potential collisions before they become issues.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
Well, we should probably clarify:
Global changes can very well be deployed using App Repo or via Source Control. There is no technical barrier. Some things to take extra care, but it works fine.
Personally, I would not use a hybrid approach. Hybrid means you have two different paths / technologies. Two different ways how something can go wrong.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
Hello @martinfaehn ,
Appreciate you framing it with both a versioning and a visibility angle, since the two are tightly linked in ServiceNow.
Also Git integrated scoped applications for versioning, and a PR + Kanban + ownership-model combination for visibility, gives the best balance of coordination and deployment safety without over relying on manual documentation that decays over time.
If my response helped mark as helpful and accept the solution.