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.

[paki]

---

@Daniel Draes wrote:

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.

---

This sounds awesome. Does a pipeline like this exist in the wild? Maybe I don't need to start from scratch.

[Brad Tilton]

It sounds like you have a pretty good understanding of how the process works and what the limitations are.

Because you can only have one active branch in an instance at a time, and publishing an app to the repo publishes the entire app, it can be difficult to have multiple developers working on the same app in the same instance at the same time, but need to deploy their work at different times.

I've seen customers get around this with multiple dev instances or by coordinating the dev work where it gets deployed at the same time in a feature branch, etc. 

[Daniel Draes]

I completely agree with Brad, you have a very good understanding of how it should be working.

As for separating changes, you basically have two options today.

a) Selective commit

When developer A commits his/her changes to the source repository he/she can select which artifacts should be commited. This allows to exclude the changes from other developers. If you instruct your developers to create their own update sets, the selective commit screen will also allow a simpler selection of who did which changes. It still requires though your developers to talk to each other as they need to take care on dependencies within their work.

Now as the relevant changes have been pushed to the git repository, the next step is to deploy them to an upstream instance. Ideally you have a separated test/build instance. Assuming this instance is linked to the same source code repository you can simply use the apply changes features from that instance to pull the changes for testing.

After testing I would recommend to use the publish to app repo feature from your test/build instance before deploying to production. However, you could also link the production instance to the same repo and also use the apply from source control function. As long as you strictly control the process to avoid accidentally deploy something untested 😄

b) separate development using branches

Source Control does allow you to create branches, but as you illuted, ServiceNow can only hold one branch active per application for a given time. This would hinder your parallel development. You either need to time-slice the instance (monday dev A, tuesday Dev B,...) or you need to have more development instances to give each independet dev a separate instance.

With the additional branches you get more options on how to move the changes through your environment. Pull Requests will essentially be the vehicle of choice, but they do add more complexity to the process.