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.

[Akshatha Balla1]

Thanks for clarifying this. But I'm wondering why this is not mentioned as a Method of Deployment in any of the Servicenow documentation. Please let me know if I missed this somewhere but servicenow still maintains either update set or publish to Application repository only as the deployment method even though its possible using external repo; it is only mentioned to use them in sub prod instances. It's highly confusing for beginners like me when they mention some method is a technical possibility but they neither deny nor agree to use it as a deployment method.

Is this just a case of documentation not being updated?

[Daniel Draes]

Partly i guess... so yes, the documention should list it as a possibility at least. We are working on additional collateral and guidance on what you should use when. My colleague Andrew will publish a new whitepaper hopefullly by the end of this month (working on the final bits...) at list outlining what the options are and how you can use them.

Next step will then be to distill the best practice on when to use which ....

[Maik Skoddow]

Hi @Daniel.Draes 

"So, nowadays you can very well link your dev, test and even prod instance to the same repository." -> this really new to me.

At the moment I am taking the CTA training and in one of our eLearnings the following picture was provided:

Using Git as a replacement for the application repository is too much of a risk for me, based on current information, to recommend it to anyone who is not a hardcore developer.

So I'm very excited to see how Git will be positioned as the new staging repository.

Maik

[Daniel Draes]

Yes, this picture is where and how we position git - it reflects our recommendation to use git as a replacement for team development. The collaboration features are where git shines and excels.

App Repo can be a big help in managing versions of applications. It is the easiest choice for most customers. And will help to remove the update set part.

I would also not recommend git as a replacement for AppRepo to all customers, it does require quite a bit of git-knowledge to use it all the way up to production (e.g. branching, merging, tagging,....). We do have some customers though being very profitient in git and for them it can be a valid option. There is no technical limitation anymore (as it used to be). 

[Akshatha Balla2]

Hi @Daniel.Draes

Any update on this whitepaper and where I can find it? I'm looking for an official documentation on this process.