how should we organize emergency fixing?
This stream should be in sync with the production stream as well as the related build workspace. Without syncing the build workspace, too many items will be built.
Sync of the stream is no problem as the developer is member of the team area owning the stream.
Problem: the developer can't sync the build workspace as he is not the owner; the build user is.
Accepted answer
One other answer
1. You can set up a green stream scenario, where the build delivers the changes after a successful build. That way, you would always have a stream that is good.
2. If the build runs against the emergency stream, the build process loads the content of that stream during builds. So it is synchronized to the stream at the moment of the load.
2. Personal builds are the best way to run a build on the changes even before delivering, in this case the build is run on the repository workspace of the user.
Comments
Hi Ralph,
We are using the ARCAD-pack for RTC. After building a release, we have to do some actions in ARCAD to actually put the release in production (install objects on iSeries = "ARCAD Distribute" + update some metadata in ARCAD = "ARCAD Transfer to reference").
When that is done, the next step is to update the production stream in RTC to have the production status reflected in RTC as well.
This is a manual task...
The production stream has no build.
When there is a production problem, we want the developers to work in the "emergency fix"-stream for which we have a build definition.
However, it needs to be synced first as well as the build workspaces... but I'm not sure how to achieve this without making averyboy JazzAdmin or sharing the builduser's password.
Regards,
Bernd.