Git is by many considered an industry standard for modern software development. ServiceNow has supported git for custom development on the Now platform for a while now.
However, as git was only available for scoped applications and then also supported only a subset of git operations, setting up git did not add a lot of value to the development process.
Let's take a look at what changed this year and why I think it is worth revisiting this topic for 2021:
Branching & Merging
The Orlando release unlocked the full git potential by allowing branching and merging in a repository and making commits of only a subset of application files significantly easier.
Branching greatly improves version management for custom applications. For example a hotfix can now be developed by branching off the current production version and fixing the issue in the branch. Compared to Update Sets, I no longer have worry about accidentally deploying work in progress from development together with my hotfix.
Additionally this can easily increase overall Quality Assurance process by adding a peer review or approval step into the pull request to make sure that any new development follows company standards and ServiceNow best practices.
Usage of Branching is explained on the Developer Portal.
Incremental loading
Previously to Paris, retrieving an application from a git repository resulted in uninstalling and reinstalling the application.
This resulted in data being lost on development and test instances and thus increasing the effort for developers to set up working test data all over again.
With "Delta" or incremental loading, applying remote changes finally only modifies your application, leaving your treasured test data intact.
A word of warning here: Compared to installing a new version from the Application Repository, the incremental loading does not perform any conflict checks and overwrites any object (e.g. a web-service endpoint) with the version currently stored in git. While this actually helps with development, it is the reason why git is still not intended for production deployment.
CICD APIs and Spokes
Also introduced in the Orlando release, the new REST APIs for CI/CD as well as the new Flow Designer Spokes allow to build a Continuous integration (CI) and continuous delivery (CD) pipeline.
This allows developers now to automatically deploy the new version to the test instance, run the Automated Test Framework (ATF) Test Cases, then publish the Application to the Company Application Repository and deploy it to the production instance.
This however requires a pipeline (e.g. in Jenkins) to be set up per Scoped Application which adds quite a bit of overhead.
Additionally orchestrating the deployment of new functionality that relies on more than one application Scope is immensely complex and still better done with Batched Update Sets.
For now I would recommend limiting this to scenarios with low complexity and a high velocity of changes.
An ideal use case would be the Service Catalog. Catalog Items are created in an Application Scope and once finished, pushed trough the CICD pipeline directly into production.
Global Scope Support
With the Paris release, Global Scope (or Legacy) applications now also support git. This allows developers working on Global Applications, e.g. Incident Management to make full usage of source control capabilities as well.
More information can be found on the Developer Portal.
Now Experience UI Framework: Developing Custom Components
The "Now Experience UI Framework" has been released in Orlando and allows developers to create custom UI components. These components can then be used in Agent Workspace as building blocks to create custom user interfaces.
Components are developed locally and then uploaded to the ServiceNow instance using the Now CLI to become part of a Scoped Application. Details on how to set up Now CLI can be found on the Developer Portal.
This is, however, a one-way street. Once uploaded, a component can neither be edited directly in the instance nor easily downloaded back into the local development environment again.
This means it’s absolutely crucial to store the source files in a solution that allows proper versioning and collaboration for multiple developers.
While this technically can be achieved in multiple ways, there is definitely a huge benefit of storing the source code for these objects in git together with the scoped application itself.
Multiple development instances
While this is certainly an edge case, linking two development instances two the same git repository allows both instances to work on the scoped application at the same time.
While this is technically also possible with Update Sets, it becomes a lot easier if both instances are connected to the same git repository and properly utilise branching.
Summary
The initial release of source control support back in 2016 (Helsinki) left a lot to be desired. However in the last two releases, the functionality received some love and is now finally catching up with the industry standard.
So, why not pick one of your applications and pilot the usage of git and the CI/CD APIs with your team?
24 Comments
