Best Practices for Managing Scoped Applications in ServiceNow Without GitHub
I recently worked with a client who wanted to develop custom applications in ServiceNow but did not use any repositories like GitHub for version control. This scenario presented a unique challenge: how to manage scoped application development efficiently while maintaining control, traceability, and consistency. The solution was to adopt a well-structured deployment process using update sets and the ServiceNow application repository.
Scoped applications in ServiceNow offer flexibility and scalability for developing custom solutions. But what happens when a client prefers not to use GitHub repositories for version control? The key is to adopt a well-structured deployment process that maintains control, traceability, and efficiency across environments. In this post, we’ll walk through a recommended approach for managing scoped applications without relying on external repositories like GitHub.
Deployment Workflow Overview
To streamline scoped application development and deployment, the following process is recommended:
Develop in the Dev Instance
Perform all initial development work in the Dev instance. Build out your scoped application, including scripts, configurations, and UI changes.
Use update sets to organize and track changes. This ensures your work can be moved across instances cleanly.
Promote Update Sets to TEST
Once development is complete, promote your update sets to the TEST instance. TEST serves as the first environment for functional validation.
Conduct thorough testing here to identify and fix any issues before moving forward. Think of TEST as the gatekeeper before your changes reach production.
Push to the Application Repository from TEST
After successful testing, push the scoped application to the ServiceNow application repository from the TEST instance.
Only allow TEST to push to the repository. Restricting this access ensures that only validated, tested changes are published to the central repository.
Pull from the Repository in UAT and Production
In UAT (User Acceptance Testing) and Production, pull the scoped application from the repository. This ensures consistency between environments and aligns all deployments with the tested version.
Why Restrict Push Access to TEST?
By limiting repository push access to the TEST instance, you achieve:
Version Control Integrity: Only tested changes make it into the central repository.
Clean Promotion Process: Development happens in Dev, validation occurs in TEST, and validated versions are deployed to UAT and Production.
Reduced Risk: Accidental or untested updates are avoided.
This structure mimics a CI/CD pipeline while maintaining simplicity for clients not using external version control.
Benefits of This Approach
Streamlined Testing: Testing in TEST minimizes errors before UAT and Production.
Traceable Changes: Update sets and repository versions provide clear audit trails.
Consistency: All environments pull from a single source of truth, ensuring alignment.
Simplicity for Non-Git Users: By relying on native ServiceNow tools like update sets and the app repository, this process remains lightweight and manageable.
Visual Workflow
Below is an updated workflow diagram to illustrate the process:
Key Takeaways
Managing scoped applications without GitHub doesn’t have to be complicated. By developing in Dev, validating changes in TEST, and using the ServiceNow application repository to distribute updates, you create a reliable and efficient deployment process. Ensuring push access is restricted to TEST further safeguards the repository, giving you a solid foundation for managing scoped applications seamlessly across all environments.
Adopt this approach to maintain quality, consistency, and traceability while keeping the process simple for your clients.
