It's all about the answers!

Ask a question

Change Management team needs to share control of stream, repository workspace, and local dirs


Alex Renko (111) | asked Aug 18 '15, 9:03 a.m.
retagged Dec 02 '15, 5:21 p.m. by Ken Tessier (84117)

We have 2-3 people who are in charge of SW build and control. Lets call them "CM". The Build platform is LINUX, while a separate Jazz server is used to house the stream and repository workspace.

How can we have multiple people "share" control of a stream, repository workspace, and local directory on LINUX? The 1st and 3rd are possible with RTC, but can they share a repository workspace?

Our desired process is as follows:

1) Developers deliver to a "staging" stream (which flows to a "prod stream")

2) CM accepts changes to a "prod stream"

3) CM accepts changes to a "shared" (if possible) repository workspace from the "prod stream"

4) The "shared" respository workspace is connected to a LINUX machine where all the software is "loaded" to. The directories on LINUX are group controlled. Only the CM group can update files in those directories.

5) CM team then builds the updated software on LINUX.

This whole process is secure, but it gets messy and un-workable if each member of the CM team has to have their own private repository workspace. Any solution here? Any way to "group control" this whole process?

Thanks,

Alex

2 answers



permanent link
Arun K Sriramaiah (3.2k12251) | answered Aug 18 '15, 11:01 a.m.
Hi Ales,

I would command to use the separate Repository workspace for each users\activities and control using the deliver option using the team area scope on the stream level and operation behaviors.

If its public Repository workspace, yes but I think  you should have admin privilege to do so.

Note: You should have separate build workspace for build.

Please find the link below for Process behavior lookup in Rational Team Concert, might help.

https://jazz.net/library/article/292

Operational Behaviors:

1) Restricting deliveries to streams

https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.scm.doc/topics/t_scm_eclipse_restrict_delivery.html&scope=null

https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.scm.doc/topics/t_scm_eclipse_process_preconditions.html&scope=null

2) Restrict Stream Visibility to be set to Public

https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.jazz.platform.doc/topics/r_preconds_followups.html&scope=null

Please let me know does that helps.

Regards,
Arun.





Comments
Alex Renko commented Aug 18 '15, 11:40 a.m. | edited Aug 18 '15, 3:25 p.m.

Hi Arun,

Thank You for the fast answer, but don't see a solution to our problem yet...

>> You should have separate build workspace for build

No, on our LINUX (build) platform we have our PRODuction repository and we should only manage one instance of that. The 2-3 "CM" people manage all files and programs there via LINUX group permissions. We have to use Jazz on a different server though. So in Jazz we have the PROD "stream", but final resting place of all of our SW must be on LINUX.

>>If its public Repository workspace, yes but I think  you should have admin privilege to do so.

Is there a way to set a "Public Repository Workspace" so that multiple people can read *and write* to it? I have not seen a way to allow multiple people to have full control and "write ability" ability into a repository workspace, but I could be wrong.  ???

Thank You,

--Alex


permanent link
Geoffrey Clemm (29.9k23035) | answered Aug 18 '15, 3:39 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
As context, in RTC, there are two kinds of modifiable configurations, personal configurations (updated by a single user) and shared configurations (updated by anyone who has write access to that configuration).
A personal configuration is called a "workspace", and a shared configuration is called a "stream".
So there is no such thing as a "shared workspace" (a workspace, by definition, is not shared).  
Note: You can have a "public" workspace, but that refers to who can see the contents of the workspace ... only the owner of a workspace can modify the workspace.  

WRT your particular question, why are steps 3, 4, and 5 manual?   Normally, they would be fully automated.  In particular, the automated continuous build is normally responsible for these steps, and the workspace used by the continuous build would be owned by whatever user account the automated build is running under (not by members of the CM team).


Comments
Alex Renko commented Aug 19 '15, 12:59 p.m. | edited Aug 20 '15, 6:26 p.m.

Thanks Geoffrey for that answer on workspaces.

We run a large 24x7 mission critical environment, and we have a very tight change management process. Also, to be PCI compliant, we require "separation of duties" such that the programmers developing SW are not the ones who perform the final build and update the PROD SW libraries. We have a team of change management folks whose job it is to promote, build, and load the final software which resides on a remote LINUX system.

Whether we automate or not, the requirement is that anyone in that Change Management team be able to deliver SW into that PROD stream, move it to LINUX and build it on LINUX. So how can we get SW which sits in a JAZZ PROD stream, to be replicated to LINUX into "group controlled" directories? Any ideas???

Is there a way for a "stream" to be connected to a remote directory workspace (and be synchronized with it) just like we can do with a repository workspace connected to a remote directory workspace on LINUX?

Thank You, --Alex


Geoffrey Clemm commented Sep 21 '15, 6:11 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

There are two main ways to get a file system directory populated with files from an RTC stream.   The first is to create a repository workspace on that stream, and then "load" that workspace at the specified file system directory (which then becomes an RTC "sandbox").   The other way is to do this operation yourself via scripting (usually using the RTC command line).
Since the RTC clients run on Linux, is there a reason why you aren't just creating a repository workspace, and asking RTC to load it?


Alex Renko commented Nov 23 '15, 6:20 p.m. | edited Nov 28 '15, 1:50 a.m.

Hi,

>>is there a reason why you aren't just creating a repository workspace, and asking RTC to load it?

That's what we are trying to do.

Let me ask a similar question. We would like to move the ownership of a "repository workspace" around between programmers A and B. We tried this - but this did not work:

Programmer A has a repository workspace sync'd to a stream. That repository workspace is also "loaded" such that when programmer A "accepts" a change set into his repository workspace from the stream, because it is "loaded" to a directory on a remote LINUX server, files are automatically uploaded to that LINUX server with the "accept".

So far so good.

We also want programmer B to be able to do what programmer A just did, such that the same directory on that LINUX server is updated. So we are able to change the "ownership" of that repository workspace from programmer A to programmer B, however, when programmer B "accepts" a change set from the stream, those files are *NOT* uploaded to the LINUX server in that same directory. It seems that the "synchronization" of a repository workspace to a loaded directory is broken when the repository workspace owner is changed. Is there a way to fix that?

This gets back to the point - We have programmers who write software, but then we have change management people who "promote and build" software. This is a common security requirement in the industry in many places and is known as "separation of duties". We want the change management people to act as a team of people who can step in and promote software into a set of LINUX directories which "only they" have R/W access to, but each of them can promote into the "same" LINUX directory. (We don't want multiple copies of the SW)

Since there is no such thing as a "shared repository workspace". Would moving the "ownership" of the workspace allow multiple people to operate on it and how do we set it up so that regardless of who is the owner of that repository workspace - it can "load" to the same remote LINUX directory? Or does each userid have to "load" it to those directories for this to work?

Any ideas?

Thanks, --Alex

Your answer


Register or to post your answer.