build scheduling visualization and complexity
Has there been any thought given to a "visual build schedule"
mechanism in RTC? I do release engineering for a project with
some 75 builds (and growing) in RTC and find scheduling builds
increasingly difficult. Certain components have dependencies on
others and so need to be built "in order"; some platforms take
longer than others; etc. We use BuildForge to drive the actual
build process but don't have (or want) all the developers, QA,
and heaven-forbid project managmenet people ;-) in BuildForge.
We'd like to keep all the build requests and scheduling in RTC.
What I imagine is something like calendering systems busy/free
time visualization for meeting organization, resource scheduling
etc. This could be something quite simple/manual where different
builds are simple displayed and be quite useful -- extra points
for being able to adjust start times from the visualization. Of
course, with all RTC "knows" about build times etc., one could
imagine a "smart" build control system with dependencies, fork
and join parallelism at the build level (like BF has at the step
level), parent/child build relationships etc.
In short, what's available and what's being planned to help
manage complex builds?
mechanism in RTC? I do release engineering for a project with
some 75 builds (and growing) in RTC and find scheduling builds
increasingly difficult. Certain components have dependencies on
others and so need to be built "in order"; some platforms take
longer than others; etc. We use BuildForge to drive the actual
build process but don't have (or want) all the developers, QA,
and heaven-forbid project managmenet people ;-) in BuildForge.
We'd like to keep all the build requests and scheduling in RTC.
What I imagine is something like calendering systems busy/free
time visualization for meeting organization, resource scheduling
etc. This could be something quite simple/manual where different
builds are simple displayed and be quite useful -- extra points
for being able to adjust start times from the visualization. Of
course, with all RTC "knows" about build times etc., one could
imagine a "smart" build control system with dependencies, fork
and join parallelism at the build level (like BF has at the step
level), parent/child build relationships etc.
In short, what's available and what's being planned to help
manage complex builds?
2 answers
Hi Michael,
Visualizing the build schedules sounds like a neat idea, but it's not something we've considered (at least not for 3.0). It might be possible to do this in a separate web UI using the (internal) REST interface used to service the web UI.
For example, get:
https://jazz.net/jazz/resource/virtual/build/definitions?_prettyPrint=true
then search for:
"scheduleEnabled": true
You can try it on your own repository too, as this interface has been around since 1.0.
For 3.0, we've made various improvements to the integration with Build Forge.
For an overview, see the RTC 3.0 topics at:
https://jazz.net/wiki/bin/view/Main/RationalBuildForge
as well as the New and Noteworthy pages for the 3.0 milestone builds. Here are the direct links:
https://jazz.net/downloads/rational-team-concert/milestones/3.0M4?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0M5?p=news#buildforge
https://jazz.net/downloads/rational-team-concert/milestones/3.0M6?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0M7a?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0M8?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0RC0?p=news#build
Going beyond 3.0, we aim to further improve the integration to the point of there being only one RTC build solution, with the ease of configuration you've come to expect, and the full power of Build Forge at runtime. Exactly what that entails remains to be seen, so we're interested in your feedback!
Visualizing the build schedules sounds like a neat idea, but it's not something we've considered (at least not for 3.0). It might be possible to do this in a separate web UI using the (internal) REST interface used to service the web UI.
For example, get:
https://jazz.net/jazz/resource/virtual/build/definitions?_prettyPrint=true
then search for:
"scheduleEnabled": true
You can try it on your own repository too, as this interface has been around since 1.0.
For 3.0, we've made various improvements to the integration with Build Forge.
For an overview, see the RTC 3.0 topics at:
https://jazz.net/wiki/bin/view/Main/RationalBuildForge
as well as the New and Noteworthy pages for the 3.0 milestone builds. Here are the direct links:
https://jazz.net/downloads/rational-team-concert/milestones/3.0M4?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0M5?p=news#buildforge
https://jazz.net/downloads/rational-team-concert/milestones/3.0M6?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0M7a?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0M8?p=news#build
https://jazz.net/downloads/rational-team-concert/milestones/3.0RC0?p=news#build
Going beyond 3.0, we aim to further improve the integration to the point of there being only one RTC build solution, with the ease of configuration you've come to expect, and the full power of Build Forge at runtime. Exactly what that entails remains to be seen, so we're interested in your feedback!
What are the recommended practices for release management in RTC? Meaning,
1. once a build is create and tested, what is the recommended practice for approving the release for deployment?
2. Also, are there any best practices in regards to providing a build workflow such as "ready_for_test" or "ready_for_deploy"?
3. Lastly, what is the recommended practice for associating a release that shows up on a project's releases tab with a release plan that shows up in a project's overview tab.
Thank you!
1. once a build is create and tested, what is the recommended practice for approving the release for deployment?
2. Also, are there any best practices in regards to providing a build workflow such as "ready_for_test" or "ready_for_deploy"?
3. Lastly, what is the recommended practice for associating a release that shows up on a project's releases tab with a release plan that shows up in a project's overview tab.
Thank you!