Intro
ServiceNow Studio provides an Integrated Development Environment (IDE) interface for application developers to work on custom applications in one centralised location.
It offers a simple way to create, review, and update application files from a tabbed environment and enables application developers to integrate with a Git Source Control Repository. This functionality allows to save and manage multiple versions of an application from a non-production instance.
Source Control enables all application developers on a non-production instance to:
- Import applications from a Git repository.
- Pull and apply remote changes from a Git repository.
- Commit all local changes on the instance to a Git repository.
- Create tags to link to a given version of an application permanently.
- Create branches to maintain multiple versions of an application simultaneously.
On the other hand, development is not just about creation.
In some extreme cases, the developers are asked to delete an application not yet published and move on to something different. This article will show how to remove an existing application and highlight the actual behaviour of the Now Platform if we need to create another application with the same name.
Development Flow - Quick Recap.
When developers work on a custom application, they can make it available to company instances by publishing it to the ServiceNow application repository.
The ServiceNow application repository is a central repository for all scoped applications published by all ServiceNow customers. The application repository allows ServiceNow customers to upload and distribute applications between their instances. When someone accesses the application repository, they can see and manage only the applications published by your organisation. Developers cannot see or manage applications that other organisations publish.
The following image shows that the content developed in DEV is published as a new version in the repo and can be deployed in any environment other than DEV.
It is impossible to publish to the application repository from different environments other than DEV.
Developers can also count on a Git Repo to back up their work while implementing their application.
In this article, we will leverage the Git Repo and avoid a direct publish over the App Repository.
Introducing the use case. Create the app.
Now imagine that we have been instructed to create a new app named Bogus.
A new empty custom app called 'Bogus' has been created and linked with a project of the same name in an existing Git Repository.
To allow the developers to work on the sprint and the stories, we must set a common strategy for them. They will work on the same sprint, and we must find a common development object between Git and the Custom Application. One thing that can help us here is the concept of the branch.
A branch is a unique set of code changes with a unique name. Each repository can have one or more branches. The main branch is where all changes eventually get merged back into and are called main (well, someone still calls it master but to cut a long story short, Git Repos renamed it).
Each custom application in ServiceNow can be set on one unique branch at a time, and if we think about the sprint as our unique set of code changes, the next step seems obvious.
|
We can create a new branch for each sprint and select it. The new branch will track all the work to implement the two stories. |
It is also essential to use a consistent naming convention internally to be followed every time a new sprint is set and executed by the development team.
In our example, we will use
- three letters as project name acronyms [BGS]
- the letter R followed by two digits for the release [R01]
- the letter S followed by four numbers for the sprint. [S0001]
The new branch is created and selected as a standard component for the developers.
The following image summarises everything done so far.
Delete the application.
For some reason, the management changed its mind, and the app is unnecessary and must be deleted.
The applications can be removed from the development environment, but the operation can't be performed in the studio. The developers must navigate under 'Applications > My Company Applications'.
Select the application from the list.
Click the 'Delete' button and follow the procedure.
After the application's removal, we can also clean the Git Lab repository deleting permanently the project previously linked with the application. The developer can log into Git Lab, navigate under 'Settings > General > Advanced > Delete Project', and follow the instructions.
After this last step, we are good to go, and both Git and our instance are back to their initial status.
The following image recaps all the tasks executed to reach the actual situation.
Recreate the application.
Fast forward a few months to the future. Another team is instructed to create a new scoped application.
Due to a series of unfortunate events, the developers picked the same name used by the old application previously created and deleted it. A new application named 'Bogus' is created.
|
This is possible because the previous scoped application never reached the private app repo. The name can be re-used if a scoped application is not published and then deleted. |
The app creation date is different if you compare the following snapshot with the previous one.
The title is also slightly different, but the application's name is the same. x_273631_bogus.
We can repeat the same process for the Git Repo, creating a new project with the same name.
The following image shows a new project in Git using the same name but marked with a different Id.
We can also notice we have just the default main branch available. This is a sign that the project is not yet linked with the latest 'Bogus' application.
Time to connect the application with the project using the URL obtained from the repo
- https://gitlab.com/my_username/bogus.git
The URL is the same one we generated for the previous project that we already deleted. This is due to the fact we are using the same names.
We set the basic config form and start the linking process.
Something unexpected happens the linking process fails, but the application seems connected with the Git Repo. In particular, ServiceNow shows that the applications are linked with a branch named BGS_R010_S0001.
This doesn't seem right. We deleted the branch while deleting the old project in Git Lab.
If we return to Git, the new project shows no branches, not even the default named 'main'.
The following image is a recap of the actual status.
Cleaning things for good.
The reason behind this strange situation is found in the Now Platform and its handling of the connection with an external repo. ServiceNow is always acting as a master dictating the link with Git, setting the branches or the commits. Tables are populated when connecting an existing Git project and a custom application-specific.
The instance, as a first thing, creates a record in a table named Repository Configuration [sys_repo_config]
As visible in the following image, the form is going to show
- URL provided by the Git project
- Reference to the actual scoped app
- Credentials used to log into the Git repo
- Current branch used by the developers
- Current reference - ID of the actual branch selected for development
The system will also generate a record into the Source Control Branch table [sys_repo_branch].
As visible in the following image, the form is going to show
- Branch name
- Object ID - ID of the actual branch selected for development
- Repository Configuration - Reference to the Repository configuration.
- Is Current - Boolean showing if the branch is selected as current
Visible in the next snapshot is the actual status of the 'Repository Configuration' after the execution of the following steps
- Application creation
- Application Link with the repository
- Setup of the new branch named 'BGS_R01_S0001'
- Selection of the new branch named 'BGS_R01_S0001' as current.
As soon as the application is deleted from ServiceNow Studio, the system doesn't delete the 'Repository Configuration' record or 'Source Control Branches'. Only the field named 'Application' is cleaned up.
Unfortunately, the external repo cannot execute direct updates to ServiceNow in this process. This means that the 'Source Control Branches' and the 'Repository Configuration' don't exist anymore and that we are leaving behind information on the Now Platform that shouldn't be there.
This disconnection between the two sides causes the side effect.
As we did in our use case, we can
- create a new project in Git with an identical name (e.g., bogus)
- create a new app in the Now Platform with an identical name (e.g., bogus)
- link the new app with the new main branch in the new project.
The system at this point does NOT create a new 'Repository Configuration' as it should be. However, it uses the existing record that still refers to a project, and branches are now available on the external repo.
In the ServiceNow instance, the 'Repository Configuration' record reverted to its status before the first app deletion, referencing the new app.
Thanks to the old 'Repository Configuration' record, ServiceNow Studio will show the deleted branch as the one selected. If you try to check the 'Switch Branch', the system shows 'BGS_R01_S0001' selected.
If we try to execute a commit without creating any file, ServiceNow Studio will allow the operation, but the sync with the repo will fail to show a new error.
This last sync operation will also affect the old 'Repository Configuration' record removing the records referring to the old 'master' and 'main' branches.
The application and the repo are inconsistent and can't be adequately used for development.
Conclusion
The scenario/side effects illustrated in the previous sections can be avoided by following simple suggestions:
You have two options
|
Cheers
R0b0
Kudos to Mr.
(2).jpg){kind=link}
