How to handle multiple deployments using Branches for Source Control in Scoped Application

[Akshatha Balla1]

Hello,

I'm fairly new to scoped application development, so please excuse me if I'm missing something basic. My understanding of scoped application is that the release to the next instances happen via publish to the Application repository and we commit changes to the External Repo (GitHub) via source control for back up. 

There's an application in my company that has several versions and it was being worked upon by only one person. Now, for the enhancement of the same, two more developers are coming into picture. The changes made by each developer has no relation to each other's codes (Dev A may have completed his work but dev B and C may still be WIP) Now we need to move the code of Dev A across instances. 

If we publish the app to the repository at this stage, the unfinished work of B and C would also be published. What is the effective way of moving only Dev A's code across instances?

PS: I looked into branching as mentioned in https://developer.servicenow.com/dev.do#!/learn/learning-plans/rome/new_to_servicenow/app_store_learnv2_devenvironment_rome_source_control_branches and while it maintains the code separately from the whole application and we can later merge it to master file in the repository, how do we move the code across instances?

I have tested by importing the master file from source control(GitHub) in the QA instance ( import from Source Control) and it addresses all of my problems but I'm afraid that's not how we move the code for scoped app.

Also, the branch seems to have a limitation where in one instance only one branch can be the current one, not different branches for different developers.

Any input on this is highly appreciated.

[Maik Skoddow · Accepted solution]

Hi @Akshatha Ballal 

unfortunately you misunderstood something.

You ONLY connect your DEV instance with a Git Repositoy. Never, really never connect all the following instances with the same Git Repo as this can cause irreversible damages!

From DEV there are the only two ways of deploying to the next stage: via Update Sets (not recommended) and via Application Repository.

And regarding Git you should know that ServiceNow does not support working on different branches in parallel. That means you can only work on one version/branch at the same time.

Kind regards
Maik

[Akshatha Balla1]

Thanks for the clearly distinguishing what is and isn't allowed. I think I got the bright idea of moving app to every instance via Git Repo by what's written here.

https://developer.servicenow.com/dev.do#!/learn/learning-plans/quebec/new_to_servicenow/app_store_le...t

But I didn't realize till now that they'd mentioned this with respect to only non-production environments. 

On a different note, is it ok to move someone's code via update set first (because it's urgent and there's other code which is WIP, so we selectively exclude/remove them from the update set) and then move everything with repository publish that includes the finishes and previously WIP codes?

Or can this selective exclusion be possible before we publish to the repository? I'm currently testing this in my PDI, so I don't have the option to publish to a repository and see how it works.

[Maik Skoddow]

Hi @Akshatha Ballal 

"On a different note, is it ok to move someone's code via update set first (because it's urgent and there's other code which is WIP, so we selectively exclude/remove them from the update set) and then move everything with repository publish that includes the finishes and previously WIP codes?"

I don't know exactly how this is meant, but what I can tell you is, that after using or switching to GiT Repository you cannot use any more additional Update Sets on DEV to bring in code via that way. 

Kind regards
Maik

[Daniel Draes]

Wanted to chime in here. There is technically NO reason anymore to not link more instances to the same repo. The fact that it could cause irreversible damages is outdated since some releases for sure.

So, nowadays you can very well link your dev, test and even prod instance to the same repository. A flow could be that dev pushes changes to the repo, test and prod only pull (apply) changes from there. This depends on how you want to use source control in our development process.

I'll answer your other question on separating changes in another reply.