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!

[Tim Woodruff]

Chuck, 

I'm curious what you think about this post about nested scopes and better scope-handling in ServiceNow. I'm curious whether you believe that it (or any of the three main points in it) are something that might be possible to implement. 

[William Busby]

Can't speak for anyone else but...

AMEN! You preach it and I'll turn the pages!

Just got your book on best practices. It's something that ServiceNow should have included in their documentation years ago. It would have shaved a few months off my learning curve.

[Tim Woodruff]

Thanks William; I'm glad you liked the book too! 🙂 

[Chuck Tomasi]

You might also find the technical best practice on the developer helpful.

Reference:

Developer: Technical Best Practices

[Joey Day]

My team and I have been using scoped apps for every new project we've done for about the last year and a quarter. We use the publish/install method to move stuff to production. There are many things we love about scoped apps, but we have some gripes, mostly to do with publish/install.

1. We’re frustrated that, when using the publish/install method to push apps from sub-prod up to prod, there seems to be no way to roll a scoped app back to a given version number. Once you've published 1.2, there is no way to go back to 1.1. The only way I know of to move back to 1.1 would be to go into sub-prod and painstakingly roll everything back using versions (or grab things out of Github for any record types that don't have in-platform versioning), then publish a new version 1.3 that is identical to 1.1, then “upgrade” production to that version. This would be an absolute pain in the rear! Thankfully I've never had to do this, but I'm just waiting for the other shoe to drop. Is there some better way that I haven't considered? We’re seriously thinking of switching to update sets with our scoped apps so we get the “back out” feature back.
2. We’re frustrated that if we start developing some major new feature in sub-prod that’s going to take some time, and then the business identifies a huge bug we need to patch immediately, we can’t do that because publish/install is an all or nothing operation. We end up having to wait to publish the patch together with the new feature once the new feature is done and tested. We know we can stash the new feature we’re working on, roll back to a previous branch/tag, patch the bug, publish a new version, and then bring the new feature back in from stash, but (a) switching to a different branch/tag is non-trivial since it destroys the whole app (!) and re-creates it (which can take some time especially if you have lots of test records), and (b) this completely halts development on the new feature until the bug fix is all done. This is another reason we’re seriously considering going back to update sets since they aren’t all or nothing. We could isolate the changes needed for the patch into a separate update set from the changes for the new feature and only push the patch. (Chuck, you detailed in an earlier comment that the recommendation is for devs to pull the app via Git into their own PDIs, and that blew my mind. That might entirely fix this pain point, but we’re going to have to try it and report back.)
3. Another niggly pain point is that when we delete something in our scoped app in sub-prod, it doesn’t get deleted in prod upon publish/install. Have you heard of this, Chuck? Is this issue somehow isolated to our instance, or does it affect all instances? Is it a bug or was this a purposeful design decision for some reason? I’ve never had problems deleting something and promoting that deletion up using update sets.
4. We’re also frustrated with our scoped apps whenever we clone sub-prod. We’ve noticed that after every clone all our scoped apps disconnect from source control. Restoring the latest version of an app (say, via an update set we grab right before the clone) and then re-connecting it to source control always commits a new version to source control (weird). We’ve found that the better way is to just delete the app after a clone and re-create it from source control. But, similar to switching branches, this can be a very time consuming process especially if the app has a lot of test data that will be dropped and need to be re-created.

I look forward to any advice you can provide about these pain points. Thanks!