Source Control/GIT Cannot Be Used in Production

[Mark Scott1]

This article also appears on my blog SNStud.io - Source Control/GIT Cannot Be Used in Production

If you saw my talk at #Know17, read my blog posts, or follow me on Twitter, you will know that I'm a HUGE Source Control advocate. Every project I've ever worked on in the last 5 years is locked away in a cloud hosted GIT repository somewhere. I had even dreamed of creating a ServiceNow integration that would allow me to manage a source code .... But yesterday, my team and I got the shock of our lives when we were told by a ServiceNow support team member that the GIT integration in Studio isn't to be used in production. Here's an excerpt from our ticket:

Thanks for taking my call with Chris from our Platform Tech team. As discussed, the clean install of the application and in turn deletion of some data (that is associated with configuration records) is expected when merging changes to an instance using Source Control.Source Control in ServiceNow is meant strictly for development purposes and does not support managing of applications on a Production instance.   From the documentation: "The source control integration does not support managing applications on a production instance. Instead, manage applications on a production using the application repository, an update set, or the ServiceNow Store."

The long story short is when you use source control to overwrite an application and take on new changes (I just hit the "Apply Remote Changes" button in Studio), there is a cascade delete that removes ALL sorts of OTHER data that you might not be aware is being removed. This was reported to us by a client in our domain separated instance. Every time we updated the application we wrote for them, all of their workflow contexts were blown away and the workflow was reset. This doesn't just happen for workflows either, SLAs, approvals and all sorts of other data is affected as well.

At this time, we're being told that promotion can still continue from sub-production instances. So going from dev to test is still ok, if you don't mind the data going funky every time you promote (we tend to clone from prod to dev and test on a regular scheduled anyway). The way to get around this is to use update sets (which I HATE HATE HATE) or stick your application into the ServiceNow repository and pull it down from production.

This has caused us a giant problem in production. We need to promote changes for our client but we have to back out the application we installed using Source Control / GIT and reinstall it with the ServiceNow Repository. It isn't as easy as it sounds according to ServiceNow. There is an open ticket and resources working with us. ServiceNow is great with their support, they don't mind getting their hands dirty to help us out. We're reworking our development cycle to incorporate this change but everything I love has been turned on it's head.

I feel like this shouldn't have happened in the first place. GIT/Source Control is a perfectly acceptable way of moving through the software development life cycle. I've been doing it for 10 years! Also, the document that was referenced mentions that it shouldn't be used in production in one sentence, on the page describing source control! The ONE PAGE I didn't read...

I'm still going to continue my fight, once the fire is out, I would LOVE to sit down with somebody from the platform team and describe how we use source control. Until that happens and the platform changes, we're stuck with promoting to production through the ServiceNow Repository.

[akaupisch]

It's not just about how we use source control, it's about the whole paradigm behind Source Control and how SN hasn't implemented it to the industry standard. This can cause a lot of confusion for developers who are used to using traditional source control. If SN doesn't conform to how SC is *supposed* to work, based on industry standards, they should consider re-branding it as Source Control Lite or something like that to help avoid confusion or point out something is different to pro-coders.

[jayw]

Looks like your blog is down, do you have a new url?

[Mark Scott1]

This is word for word from the blog article. If you need any clarification, please reach out!

[brittany_sorrel]

Thank you so much for sharing this! We have been working on a scoped application and using github to store the changes and move the code between dev/test environments. 

Our experience has been that if we have the application on a test environment with data setup to run testing and then click apply remote changes, poof all the previously entered data is gone for all the tables associated with the application. According to ServiceNow this shouldn't happen. Next when applying remote changes it uninstalls and then reinstalls the application which is not something I have ever heard of a source control system ever doing. We currently have a HI ticket opened for the data deletion and I will update this with their response later.

[Kyle Cribbs]

3 Years later and it seems like it is still that way. 

Any traction? 

[Daniel Draes]

Just found this post on searching something else... Wanted to update with newer knowledge 😄

While the above was true (and bad) when our Source Control integration was brought to live, we have learned and ammended.

With the Paris release we added so called Delta Loading to our source control integration:

Delta loading | ServiceNow Docs

Finally this allows source control to be used all the way up to production if you need or want it. The general recommendation for our customers though is to use Source Control as a means of development collaboration (replace team development) and use Application Repository for deployments. Both can work hand in hand together nicely. As with most features in ServiceNow, this is our recommendation but you can change and tweak it.

[kim-lindgren]

I had this problem when I used Git to export an application from a lab instance to a PDI. All the tables were wiped, not just transactional data but some very important base records as well. This was only around four months ago now. I'm pretty sure I clicked "Apply Remote Changes" or something similar. But the problem is, as far as I can tell those records were not saved to Git in the first place. Perhaps I am mistaken, but I don't think they are there (e.g. the Time Slot table should have around 200 records, one would think they would be possible to find even though I don't know exactly how to navigate all the XML).

[Daniel Draes]

@kim-lindgren It is important to understand the differences between configuration and data. The records in your custom created tables are data, and as such, they are not captured by ANY means we use to deploy changes. Not in update sets, not on AppRepo and also not in Source Control. There is one exception, if your custom table is extending sys_meta. This pattern means the records in the table have to be treated like configuration.

You can use this pattern if you want some config values to be moved from instance to instance. It should not be used for anything where you expect users of your application to change content frequently on production.

[kim-lindgren]

@Daniel Draes Interesting! I believe the table name is sys_metadata, no? This docs article explains it pretty well:
https://docs.servicenow.com/en-US/bundle/utah-application-development/page/build/applications/concep...

So if I create a custom application including the tables Room, Room type, Time Slot, and Booking, I can simply extend Time slot and Room type from sys_metadata and they will be treated as configuration tables.

I asked a similar question in a different thread and the response I got there was to use the update synch dictionary attribute on the table to make sure they are captured in an update set. Is it correct to say then that tables should only extend sys_metadata when they will have a very structural role in the application  ('Room type' may be in question here, as users may want to add more types) whereas you can sometimes use update synch to capture changes from data tables if you have to?

EDIT: This makes me wonder why I have never heard of the sys_metadata table in app development courses. It seems like a very basic thing to know when creating your own application, "if this is going to be a configuration table, it should extend the system Configuration table".

[Daniel Draes]

Technically, update_snych is the old way before we had Scopes...

What is Metadata in ServiceNow? 

The sys_metadata table and its extensions are the tables that contain records defining system configuration that determine how the platform behaves.  These records are sometimes referred to as Application files.  By extending sys_metadata, the configurations inherit scope awareness and are automatically included in applications and update sets. 

How does Metadata relate to update sets? 

Prior to applications, the only mechanism of deploying configurations to other instances was via update set.  The update set contained a collection of sys_update_xml records with payloads that defined the record to be updated.  Historically, the update_synch attribute controlled the inclusion of a particular table in an update set. 

When applications were introduced and sys_metadata created, the use of update_synch independently is no longer permitted.  It should only be used on sys_metadata extensions.