Change Management team needs to share control of stream, repository workspace, and local dirs
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
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
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
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
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
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?
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