Properly deploy changes using Team Development

[Dawn Jurek]

Coordinating application development within your organization can be like herding cats. One developer's code may collide haphazardly with someone else's, creating change conflicts that must be resolved. Developers may not be sending changes to—or retrieving changes from—a common instance. Total chaos could erupt! ServiceNow provides a number of development tools that may be the catnip to tame your development process disarray.

What tools does ServiceNow provide for development?

• ServiceNow Studio for developing Scoped applications, with built-in Source Control Integration.
• Application repository for making versions of an application available to all company instances.
• Update sets for moving a group of configuration changes from one instance to another.

Team Development is another option that you may be using. In this latest installment of our best practices series, we describe how to tame this complex but powerful system by deploying changes properly.

What is Team Development?

Team Development supports parallel development on multiple, sub-production ServiceNow instances, where each instance acts as a source repository, or branch. Individual developers use separate sub-development (sub-dev) branches to work on different features, applications, or product releases at the same time. In the development environment, the sub-dev instances are peers with a common development parent (dev-parent). Changes from all developers working in the sub-dev instances are integrated and stabilized in dev-parent prior to testing and eventual release to production.

Best practice for deploying changes when using Team Development

When using Team Development, push changes only from sub-dev instances to a dev-parent instance. Team development functionality is not intended for pushing changes to test or production instances. To deploy changes in the production pipeline, use update sets instead:

Why not push changes to test or production instances?

If it becomes necessary to back out a change on a team development instance, the backout goes all the way back down the chain, also undoing the work on the source instance. This can cause major problems on test and production instances. Update sets, on the other hand, can be backed out without affecting the source instance.

Also, using update sets in the test and production pipeline, as shown above, allows you to clone from production to test instances when your test users need newer data, without impacting your development process and instances.

For more information on Team Development, see

• Team Development
• When to use Team Development
• Team Development setup
• Set up an instance hierarchy
• Backing out an update set
• Achieve your process goals with Team Development, update sets and applications.

Check out the Developers Portal to learn more about the ServiceNow development tools at your disposal; no cat herding required. And in the meantime, don't let Team Development run amok with your development process.

--

Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series aims to target those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.

To access all of the blog posts in this series, search for "nowsupport best practices series."