The CreatorCon Call for Content is officially open! Get started here.

Is Team development still in use? Are you using it?

Suggy
Giga Sage

1. Is Team development still in use? Are people still using it?

In this video, SerivceNow talks about Update set, Source control and App repo. Meaning Team development is forgotten?

https://www.youtube.com/watch?v=TOZOWG6Mk4A

 

2. I heard sometime back ServiceNow saying, Use source control over Team development. But source control is only for scoped app while Team development can be used for global apps also right?

 

 

3 REPLIES 3

scottl
Kilo Sage

Never touched it in all the years (over a decade) working on the platform, including with other dev teams within the same environment(s)

The first question you need to ask yourself;

  •  Are you a certified SN partner that is creating an app, for the SN App store?

If yes; Maybe
--- 
If No; Don't bother, just stick to Update Sets, batching and exporting into an instance. Forget "Update Sources" and the syncing between instances, as that is horrible too, due to the excessive update sets you need to open every time a change is made, like a spelling mistake. Because it will refuse the update because someone at SN thought that was a good idea, regardless of the UPDATED ON field.  And let's not mention the conflict of update sets that have the same name when exporting several times into an environment and it breaking the COMMIT!

Forget Studio, a complete waste of time because in the real world you'll need to update records in the Global scope anyhow.

Don't pollute already existing application scopes that have been installed from the store with your additional functionality. (Can't believe people do that! )

And anyone using the Update Application for internal scoped apps, you need to be fired because it adds a huge amount of overhead moving to other instances, outside of just moving Update Sets. Because if a DEV moves a change in that application and they don't know about it being a scoped app that uses an Update App process, and moves an update set of that application, it breaks the App sync. (well done SN for that horrible experience.)  

Only create an internal scoped application IF, you want it to be turned off at a later stage. because most of the time you will be working within the Global scope anyhow. But of cause SN has made a mess of that too with all the internally scoped records on the platform, thus using studio for development a waste of time, and source control.    

Hope that answered the question. 🙂


WillieW
Tera Contributor

I suggest you find another job. We use Update sets and publish applications to the Servicenow repository. Higher instances can update retrieve/commit update sets, and update the applications from the repository. Has worked well for us for since starting with Servicenow.

Dipu Joy
ServiceNow Employee
ServiceNow Employee
Team development has been utilised by organizations since the pre-Geneva days, a time when scope functionality was not yet introduced, necessitating multiple developers to handle various projects across multiple development instances. During that period, organizations followed a working development cycle that remained consistent and supported. Although there were discussions about depreciating these methods, and documentation was lacking for one of the family releases, the practice eventually resurfaced and is available in Y doco.
 
Team development remains viable for organisations with more than two development instances and one DEV master instance, which consolidates development efforts until reaching the DEV master. From that point onward, customers should employ source control and update-set methods to transfer developments to UAT, TEST, PREPROD, and PROD environments.
 
This approach continues to be supported and is used by numerous customers who adopted it during Servicenow's early days, many of whom are large-scale enterprises. In my experience supporting these setups, issue resolution can take weeks, resulting in significant man-hour wastage for both customers and support teams, as troubleshooting is time-consuming with the reconciliation process. Additionally, improper usage in production environments can lead to wiping out the sys_metadata with incorrect/partially developed configurations. 
 
ServiceNow has made substantial progress in developing more efficient modules and products that perform the same tasks significantly better, and to utilise this, if you are a new customer. As this module is mentioned in the Y documentation, this will still be supported via a case on NowSupport.