Are you still developing in the global scope?

[Chuck Tomasi]

I'm hearing more and more that a lot of people are still developing their solutions in the global scope despite all the great development advancements we've built in to the platform (e.g. Git integration, Studio, delegated development, publish/install, etc.). Our platform business unit has the vision that we should all be building using scoped apps. This includes new apps as well as extensions to existing applications (even in the global scope.) I'd like to know what's keeping you from realizing that vision. Examples may include:

• There is a scripting API that is not available to scoped apps
• Our requirements force us to use synchronous Ajax
• We are still on Eureka
• I love update sets!
• I just don't know enough about creating scoped apps (and that's OK.)

Specifics are always appreciated. Thanks!

[Chuck Tomasi]

I have passed on a link to your comments to our product manager. Thank you!

[John Caruso]

The answer for #1 rolling back to a prior version, from my perspective at least, is found in your #2 issue:

1. Create Branch from tag of version prior to the installed version (1.1).
2. Publish this as version 1.3 (or perhaps 1.1.1) and install in prod.

For issue #2, I can confirm that using a personal dev instances works well to allow for both bug fixing and adding new features. 

I do the initial creation of an empty scoped app on the customer instance, then immediately link and push to git.

From that point on, I work from my personal dev instance.  I get a new feature working on my personal dev instance, then switch to the customer sub prod and pull in my changes (merging conflicts as needed). 

This isolates my activities from other developers and provides for a much more stable environment. 

For issue #3, I've noticed this behavior as well (at least on Jakarta Patch 7). I suppose you could argue rather than deleting something, it should be set inactive. Although I'd prefer deletes get propagated with installs.

I'm not sure about issue #4. I do know I had issues with cloning back if the app wasn't originally created on the sub prod instance.

Edit: Forgot to mention, I absolutely agree that switching branches (and pulling remote changes) can be pretty painful. But, I'm happy to put up with the occasional pain for the benefits they provide.

With respect to destroying the whole app, this is pretty much the way git works (although I think ServiceNow could optimize things by not deleting/recreating things that haven't actually changed - which should also significantly speed things up).

I tend to keep things like test data in xml exports, or rely on some type of data sync from prod (or qa, if available). My current client has a nice xml table syncing solution that makes it very easy to restore data that gets blown away when I pull my remote changes. I believe London will have some syncing solution as well, which may help in this scenario.

[pawel_st -then-]

Consider publishing schema changes and code changes separately.

It looks like "London" will still have no roll-back for custom apps and the only way is to uninstall and install old version which sucks when you have data in app. 

But when you publish schema and scripts separately, you will rarely need to roll-back schema and uninstalling code only has no impact on data.

Thoughts?

[Fabian Kunzke]

Hello,

I like to use applications a lot, especially when they are reusable within multiple plattforms. I have run into some issues though with cross-scope access when trying to implement applications which might not be useful, but technically challenging. This for example includes the ability to generate some sys_ objects (such as businessrules).

Furthermore there are some scripting APIs relevant (e.g. the GlideImpersonate) when developing applications to simulate behaviour.

Overall i really like development with applications when implementing "normal" business requirements. For projects beyond business requirements though, it really seems to be limiting. But then again, since these kind of applications are of no current use, i do not mind.

Greetings

Fabian

[pawel_st -then-]

"what's keeping you from realizing that vision?"

IMHO many companies starts with small changes to global applications like Incident.

Next they get another change and another ...

Finally they have so many custom code that replacing it with custom application is too high effort.

The migration tool (or kind of scope extraction) would help.

If I could get e.g. Incident custom code extract into custom app, test it and release  on clean instance of new release that would be "wow". I think it is possible to file custom code, classify that as "Incident", "Change", ... "Other not classified" is probably a challenge, but think how big advantage it would be for upgrades, when I could get module by module (app by app), certify that and install on new release. 

Not all companies have large dev team to release big changes quickly.