How can we clone a studio application?

nealratner · ‎05-18-2017

Alright...I really hope someone out there is trying to do the same thing. We want to build a template application and then have different versions of that application so that we can easily modify tables or add enhancements within a specific scope. Servicenow currently writes to files in a scope with "x_companyabbreviation_appname." I was hoping I could push the app to GitHub, create a new branch or fork, find and replace "appname" with "appname2" and then create a new application by importing from source control. What I found was that ServiceNow pushes a "checksum.txt" file that appears to have some sort of identifier for the application as well that is heavily encrypted.

Does anyone out there have any idea how to clone or copy an application within the same servicenow instance? Would this work in Domain Separation?

Any help would be greatly appreciated!!!

JennyHu · ‎07-21-2017

Hi Neal,

You have some really great tips! I do like your approach of not extending any table. It makes me rethink if extending the basic TASK table is the right thing to do in my scenario. My application does require some fields from the TASK table such as 'Assigned To', 'State', but not all. I guess creating from scratch is cleaner. You don't end up with database fields that are not needed.

A question that comes to my mind is, which method would require more maintenance and testing when it comes to ServiceNow version upgrade? If we do extend core tables such as TASK, and use the Service Management App Designer. I suppose if the core changes, it may impact our custom apps. But if we build everything from scratch, there's less compatibility issues as there's less dependency? Not counting the SN API changes..

Thanks,

Jenny

nealratner · ‎07-21-2017

Again, we fall outside the "norm" of ServiceNow users, but at the same time, I have done all the things you are talking about. What you mentioned is correct, If your app/table can leverage the OOB functionality from Task, Service Order, Work Order etc...then it's a consideration. As you really open the "hood" and look, you find that SN terminology differs from a traditional ETL database. For instance, "extended tables" are really more like a traditional database "view" and a ServiceNow "database view" is basically a Join. Reference fields are like primary keys and so on. You will notice I keep saying "like" because they are not direct replacements. I found myself overriding dictionary entries and turning off clients scripts/ui actions more than we could benefit from them. Again, we use ServiceNow for Oil and Gas field inspection and don't use it for an ITSM tool at all.

At the end of the day, building from scratch means I know what I built and don't have to reverse engineer some functionality that is occurring from an OOB state to know if I need to use it or turn it off. On the flip side, we code quite a bit so that would be the trade off..

JennyHu · ‎08-04-2017

Hey Neal,

I'm now using the publish to application repository method to move my application. So far it seems to work well!

One thing I have a question about is where and how do you keep your dev work? For example, I've Phase 1 and 2 changes on our development instance. However, I only wanted to publish the Phase 1 changes to the app repository as Phase 2 changes are not complete yet. I wanted to be able to push out any hot fixes or bug fixes to the app repo without publishing my dev work. What is your process to separate the dev work from changes ready for production?

Thanks,

Jenny

nealratner · ‎08-04-2017

Hi Jenny,

I have a few questions and want to make sure I understand correctly...

Are you implementing some type of version control in naming? SN allows the developer to expand version as an integer "X" or major enhancement, "X.XX" where you would make minor enhancements, and finally "X.XX.XX" where you can promote micro enhancements or bugs. Are you developing and publishing synchronously or asynchronously? Meaning, did you complete "Phase 1" completely and then move on to "Phase 2," or did you start working on phase 2 prior to the completion of phase 1.

Why this is important is because if your answer is the latter, SN does not currently provide a proper solution for "branching" or "forking" development which are quite common with GIT, Mercurial, Subversion and others. Hopefully, this is not the case. If you have completed phase 1 and are at a "stopping point," you can set the application version accordingly and publish to the SN Repository. At that point, you can import the version from your Test or Prod environment if you like, but are not required to utilize that version. In a sense, by publishing to the SN Repository a bit more often, you can have multiple versions, but also get around the lack of ability for SN to have branches and forks. Example:

You Publish the following:

0.1.0

0.1.1

0.1.11

0.1.12

0.12

Then, from Test/Prod, you can install any one of those. Here is where there are limitations again, once you install a version on a SN instance, an older version is no longer available. So, if you install "0.1.12," you could ONLY upgrade to "0.12" after and would no longer have access to older versions.

Taking this approach along with some proper preparation, you can definitely achieve a comprehensive version control and promotion pattern; but planning is half the battle! We utilize tools like CA Agile (formerly Rally) for Agile planning (SCRUM). SN has an Agile planning solution, but we are a smaller team and needed a modified version to fit our model. After making some changes to the SN Agile solution, I basically found I was just trying to change it to match CA Agile because we like it so much. Find what suits you...

Happy coding!

JennyHu · ‎08-08-2017

Hi Neal,

Thanks for your reply! I do implement version control in numbering the versions. But unfortunately, I'm the latter case. I started experiencing with Phase 2 prior to the completion of Phase 1. I'm accustomed to using Git and branching out, and since I'm not using Git on my SN DEV instance.. I'm trying to figure out another way to keep my "main" branch clean and separated from a feature DEV branch.

You brought up a good point with planning. Currently we are not using any agile planning tool. We are a fairly small team as well. I will look up SN's Agile Development module and see if it suits us.

Thanks and have a great day!

Thanks,

Jenny