- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2016 10:36 AM
I've read Chuck's previous reply in: https://community.servicenow.com/thread/225776?q=clone%20application
This mostly answers my questions, but wanted to do a final sanity check since this is the first time we've used this approach.
I have an application that I began in my personal DEV instance. I've pulled it into our corporate DEV instance via GIT and have continued to work on it in studio (Helsinki). Now its time for QA, so here's my proposed approach:
- I'm thinking that our corporate DEV instance should have the only interaction with our GIT source control, so I'm going to publish the application on DEV, and promote to TEST and PROD by way of update sets.
- Then, according to the link above if I'm correctly understanding, I should delete the application from DEV instance.
- After the CLONE, I should again pull from GIT, and continue ongoing development in the DEV instance.
If this appears to be a correct course, I wanted to make sure I can pull the application a second time, from GIT. I think I've run into problems in the past, trying to pull from source code, a second time since remnants of the application remain, even after an application deletion. Is this solved by the CLONE down from PROD?
Thanks in advance your advice!
Solved! Go to Solution.
- Labels:
-
Scoped App Development

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2016 11:09 AM
Hi Mitch,
You are correct. Dev should be the only app interacting with Git. To do otherwise would jeopardize the app data on that instance any time you install or switch branches.
You MIGHT (read: i haven't tested this yet) be able to use the publish/install feature despite the app being started on a personal developer instance. I would try that before going the update set route to get your app from dev-->test-->prod. Much easier when it comes to scoped apps. If it doesn't work, you always have a fall back plan of update sets.
Regarding the need to delete before the clone, don't worry about it. You can pull the app from source control (Git) as many times as you like. I do it all the time. It does the "wipe and replace" method each time - which is why you don't want to use it on any instance except Dev.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2016 11:09 AM
Hi Mitch,
You are correct. Dev should be the only app interacting with Git. To do otherwise would jeopardize the app data on that instance any time you install or switch branches.
You MIGHT (read: i haven't tested this yet) be able to use the publish/install feature despite the app being started on a personal developer instance. I would try that before going the update set route to get your app from dev-->test-->prod. Much easier when it comes to scoped apps. If it doesn't work, you always have a fall back plan of update sets.
Regarding the need to delete before the clone, don't worry about it. You can pull the app from source control (Git) as many times as you like. I do it all the time. It does the "wipe and replace" method each time - which is why you don't want to use it on any instance except Dev.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-25-2016 02:11 PM
As always, greatly appreciated, Chuck!