It's all about the answers!

Ask a question

Selective Synching Across two (or more) BF Instances


Jeffrey Gordon (961310) | asked Jun 15 '11, 8:27 a.m.
We have two distinct Build Forge instances in our environment. Different application teams are assigned to one or the other for all of their projects to do builds, etc. We do, however, have a set of common libraries we provide for consistent integration with a number of tools.

The problem we are trying to solve is keeping the two instances in sync with respect to this common set of libraries and, of course, any associated environments, log filters, etc. One of our engineers has suggested doing selective replication of the backend DBs (oracle for us). This seems both tricky and dangerous to manipulate the DB without Build Forge's "knowledge". Anyone think this is a good/bad idea?

Has anyone solved this particular issue and would you be willing to share your general approach. I'm sure it can be solved with the services API but this will take a lot of code. Just want to be sure we start down the best path.

--Jeff

3 answers



permanent link
Brent Ulbricht (2.5k11) | answered Jun 15 '11, 10:31 p.m.
JAZZ DEVELOPER
We have two distinct Build Forge instances in our environment. Different application teams are assigned to one or the other for all of their projects to do builds, etc. We do, however, have a set of common libraries we provide for consistent integration with a number of tools.

The problem we are trying to solve is keeping the two instances in sync with respect to this common set of libraries and, of course, any associated environments, log filters, etc. One of our engineers has suggested doing selective replication of the backend DBs (oracle for us). This seems both tricky and dangerous to manipulate the DB without Build Forge's "knowledge". Anyone think this is a good/bad idea?

Has anyone solved this particular issue and would you be willing to share your general approach. I'm sure it can be solved with the services API but this will take a lot of code. Just want to be sure we start down the best path.

--Jeff


Hi Jeff,

I was curious if you've tried or thought about using the export/import utilities for the libraries. By setting various options with bfexport/bfimport, you can have it drag along the environments and filters associated with the libraries.

Brent Ulbricht
RTC Build Lead

permanent link
Jeffrey Gordon (961310) | answered Jun 15 '11, 10:40 p.m.
We have two distinct Build Forge instances in our environment. Different application teams are assigned to one or the other for all of their projects to do builds, etc. We do, however, have a set of common libraries we provide for consistent integration with a number of tools.

The problem we are trying to solve is keeping the two instances in sync with respect to this common set of libraries and, of course, any associated environments, log filters, etc. One of our engineers has suggested doing selective replication of the backend DBs (oracle for us). This seems both tricky and dangerous to manipulate the DB without Build Forge's "knowledge". Anyone think this is a good/bad idea?

Has anyone solved this particular issue and would you be willing to share your general approach. I'm sure it can be solved with the services API but this will take a lot of code. Just want to be sure we start down the best path.

--Jeff


Hi Jeff,

I was curious if you've tried or thought about using the export/import utilities for the libraries. By setting various options with bfexport/bfimport, you can have it drag along the environments and filters associated with the libraries.

Brent Ulbricht
RTC Build Lead

My concern with export/import is that it doesn't handle snapshots properly.

permanent link
Brent Ulbricht (2.5k11) | answered Jun 16 '11, 9:26 a.m.
JAZZ DEVELOPER

My concern with export/import is that it doesn't handle snapshots properly.


Another curiosity, any thoughts about moving to one Build Forge instance?

Brent Ulbricht
RTC Build Lead

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.