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 repository in the platform . 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.