Service Portal, Git integration - Best practices

[josephdt12]

Interested in what's the best practices when using version control and having multiple developers, but only one/two instances:

Is working out of a personal development environment frowned upon?

If we can only work out of one instance or two instances, should we use Team Development or standard update sets instead of trying to link with version control?

Main issue is with two instances (not counting personal), only one branch can be used per instance. Curious to hear about anyone else's practices.

[sergiu_panaite]

This thread might help:

Benefits of integrating ServiceNow with Git

[kclark1]

Hey Joseph,

We're just starting to look at Git source control for our development in our team.   We found this video to be pretty useful:

TechNow Episode 26 | Source Control, New in Helsinki - YouTube

My main takeaways are as follows (happy to be corrected by the community though - as I say, this is new to us):

1. Dev team members can have their own Developer instances hooked up to the same Git repository.   That way, you can pull current versions of the Master and any active branches.

2. If you want to merge code between branches and back into the master, you need to make sure you create a Stash of your local changes BEFORE you commit to the repository.

3. There's no easy way to merge code back into the master outside of Stashes - if you forget to stash before you commit, then I suspect you'll probably need to make a minor change to the file so that it writes the entire XML of the file to the update set again, then you could probably save it as a stash again before manually applying the stash back to the master branch.

4.   Be careful of data - every time you switch branches or pull code from the repository, you will wipe any table content - I imagine that the 'usual' update set rules about what is considered data and what isn't would apply (like when dashboard pages need to be unloaded or some of the other edge-case files which aren't considered part of the update set).

Will try to remember to post back here with any other thoughts as we work through this.

Kevin

[kclark1]

Also, in the video above, ctomasi and the guys call out the scenario where a team is using a single instance with Git repos as particularly problematic as you've pointed out - if you switch branches, you wipe the data out and any local changes.  

I think a better way would be to have your "working" code deployed only to your main developer instance for integration testing and publication to other instances once commits have been made to the master and only pull the master code when it's ready to your main developer instance via GIT.   That way everyone can work on their own branches in their own developer instances and make a call to migrate their stashes across to the master, which can then regularly be pulled to your main developer instance.

[josephdt12]

Thank you for your answer Kevin! Very informative.

The "stashing before commits" seems like the best idea - will deal with the checksum being different for sure.

To clarify, do you not seem to use branches often as a result? Once master deviates from a branch I'm not sure the stashes could resolve it (need to pull master changes into that branch, which will conflict). Or in that case, stash for each commit so you resolve each of your stashed "commits" up until master?

Thanks again for your help though, been difficult trying to work out a viable solution!