It's all about the answers!

Ask a question

What is the recommended jazz source control setup for RTC extendability?


Dustin Walker (282) | asked Dec 11 '19, 10:52 a.m.

 I have been reviewing https://rsjazz.wordpress.com extensively and also have followed along with the development lab shown here: https://jazz.net/library/article/1000. All the information has bee extremely helpful in the development of RTC plugins. My question now is what is the most sensible or recommended source control layout for a team with this development? We are in process of revamping an old project source control space and want to make sure that the stream/component layout helps clarity and reduces deployment pain and technical overhead.


Comments
1
Ralph Schoon commented Dec 11 '19, 11:37 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I have built in my opinion about how this would be structured into  https://jazz.net/library/article/1000.Based on a separation of a client SDK and a Server SDK, i would split into components for
  1. Server development
  2. Common (shared between client and server)
  3. Client development
  4. Separate the deployment part - feature, update site
It is more complex than the initial approach when there was only one SDK, but it allows you to separate client and server development and testing.

Others that actually work in teams could respond.

Dustin Walker commented Dec 11 '19, 12:58 p.m. | edited Dec 11 '19, 12:58 p.m.

That helps greatly. Thank you! In terms of component 4 you listed, We have multiple operation behaviors we have developed. Do we need a feature and update sire for each one? I am curious how to simplify the way we deploy and manage multiple extensions. 


Ralph Schoon commented Dec 12 '19, 2:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You are very flexible in what you bundle. As far as I can tell, it is your decision, if you want to bundle multiple extensions into one feature or keep each one separated. As long as all the required dependencies are available in the feature you should be good.

There are obvious tradeofs in deploying one or many features. Note that you want to package the client/common parts like you treat the server part.

Again, I have not had the need to play around with this extensively.

Be the first one to answer this question!


Register or to post your answer.