Team Development Setup

eugenest
Mega Contributor

Hi SN experts, I need help with Team Development setup, I study all possible SN docs online, and searched via WIKI, Community and here but couldn't find answer for a few things which are not clear to me. Hope to get your answers.

Here is our SN Setup:

Prod -> TEST -> DEV instances.

       

        As our team growing we decided to try Team Development application/module to deliver our code to Prod from Dev but I am a little confused to complete the Team Development setup.

Based on the below picture from SN docs, I should be able to create multiple Sub-Dev instances/environments for each my dev but I have no idea how to do it. I feel like I am missing something here.

Screen Shot 2017-10-24 at 10.49.36 PM.png

When I go to my Dev instance within Team Development section then so far I can only create remote instance (which is TEST) from "Team dashboard" module and then can Pull from Test make a changes then Push to Dev-Parent and it will create a local update set (that is what I got from this video: ServiceNow Team Development Demo - YouTube ) .  

Please let me know if I can configure multiple Sub-Devs on my https://dev.service-now.com instance or if not then how this should be done?

Is possible to have multiple branches? ( like github has). When one task on hold i can switch to another task and complete it from another branch.

A lot of " thank you" for any advises and answers.

1 ACCEPTED SOLUTION

Patrick Schult2
Giga Guru

Team Development isn't intended to work with multiple "branches" on the same instance, it's meant for multiple development instances. If you were to reproduce the diagram you showed exactly, you would have SIX instances, 4 dev, 1 test, and 1 production. You cannot create these on your own - you have to purchase these separately.



The parent dev instance would be: dev1.service-now.com



These are the individual dev instances:


Dev2.service-now.com


dev3.service-now.com


dev4.service-now.com



Test instance: test.service-now.com


Production: production.service-now.com


View solution in original post

9 REPLIES 9

meg6
Kilo Expert

Hi Patrickschulte/eugenest,

As per my readings till now , team development will work with more than one developer instance.What if we have only one developer instance and multiple developers working on that?

How does it work provided one instance with more than 2 developers?

 

Thank you 

 

If you have one development instance, then you use Update Sets. In this setup, good communication between the developers is important to reduce work conflicts and smooth transitions to Test. 

I have been working in teams of 2-3 total people for a few years - this practice of a few people working in the same instance is perfectly fine. If you are working with a larger team it might be more challenging. If you are concerned about it, chat with your account rep and see if you can get some more sub-production instances for cheap.

Hey Patrickschulte, 

Thank yo so much for the answer, 

We are also 3 developers working on the same dev instance, It will be more helpful if you share the best practices that you and your team followed.

how did you manage with Update Sets?

is it creating 1 update set for all?

Or separate update set and merge it before pushing to parent instance

 

Thank you in advance

 

We manage update sets using a Visual Task Board, where the lanes are each of our instances - sandbox, dev, test, production. When one person is finished with an update set, it is assigned to someone else on the Visual Task Board for review and testing.

Our practice for update sets is to build them around a function or problem being fixed, rather than the person doing it. We move update sets through our test instance and deploy to production as fast as is reasonable. Getting update sets deployed quickly lets you spend less time figuring out if you need to deploy thing A before thing B, or vice versa.

I would discourage the use of a single, merged update set to move to the next higher instance unless it's for related functionality. The best practice is to keep update sets as small as you can - it's easier to read, understand, and test. Having an update set that contains hundreds of updates is much more complicated to test than smaller, more contained update sets.

There is a guide on update sets in the Docs, which describes some more best practices.

Thank you so much Patrickschulte. Its really great information for me to start with update set.